fix: crash in background with ExpiringActivity - WPB-23839

[netbe]

WPB-23839 [iOS] Crash CoreFoundation: __CFRunLoopServiceMachPort + 160

Issue

The app was being killed by the iOS watchdog with termination reason FRONTBOARD 0xBAADCA11 after running
for ~6 hours in the background. The crash was observed in TestFlight (Wire 4.16.0 / build 17993, iPhone
18,1, iOS 26.3).

  Exception Type:  EXC_CRASH (SIGKILL)
  Termination Reason: FRONTBOARD 0xbaadca11

  Thread 14 (crashing):
    semaphore_wait_trap
    _dispatch_semaphore_wait_slow
    closure #1 in closure #1 in ExpiringActivityManager.withExpiringActivity(reason:block:)
    ExpiringActivity.swift:79

0xBAADCA11 ("bad call") is the watchdog timer — iOS killed the app because it blocked a system-managed
thread indefinitely.

Root cause in ExpiringActivity.swift:

performExpiringActivity's callback must block its thread until the work is done (Apple API requirement).
The implementation used a DispatchSemaphore for this:

// expiring = false branch
Task { try await self.startWork(block: block, semaphore: semaphore).value ... }
semaphore.wait() // ← blocks the callback thread

// expiring = true branch
Task { try await self.stopWork() } // cancels the inner task
// ← semaphore is never signaled if block() ignores Task.cancel()

When expiring = true fires, stopWork() calls task.cancel(). If block() is a cooperative caller that
checks Task.checkCancellation(), the inner task exits and its defer { semaphore.signal() } fires
normally. But if block() does not cooperate with cancellation — which is a valid real-world scenario —
the inner task keeps running, semaphore.signal() is never called, and semaphore.wait() blocks the
callback thread indefinitely until the watchdog intervenes.

A secondary bug was also present: if expiring = true fires before the actor executes startWork (a race
condition), self.task is nil, stopWork() throws, and continuation.resume(throwing:) is called. When
startWork later runs and block() completes, continuation.resume() is called a second time — undefined
behaviour on CheckedContinuation.

Solution:

Two changes:

1. The expiring = true branch now always signals the semaphore and resumes the continuation directly,
   without relying on the inner task to do so:

  Task {
      do {
          try await self.stopWork()
          finish(.failure(CancellationError()))   // resume caller immediately
      } catch {
          finish(.failure(error))
      }
      semaphore.signal()   // always unblock callback thread
  }

This guarantees the callback thread is unblocked and withExpiringActivity returns to the caller
regardless of whether block() cooperates with cancellation.

2. All continuation.resume() calls are routed through OnceAction, a simple NSLock-guarded wrapper that
   ensures the continuation is resumed at most once. This eliminates the double-resume race and makes the
   fix safe.

Testing

• testBug1_ActivityCompletesAfterExpiry_WhenBlockIgnoresCancellation — verifies withExpiringActivity
  returns promptly on expiry even when block() loops with Task.yield() and never calls
  Task.checkCancellation().
• testBug2_NoContinuationDoubleResume_WhenExpiryRacesBeforeStartWork — verifies no double-resume occurs
  when the expiring = true callback is processed by the actor before startWork.

---

Checklist

• Title contains a reference JIRA issue number like [WPB-XXX].
• Description is filled and free of optional paragraphs.
• Adds/updates automated tests.

---

UI accessibility checklist

If your PR includes UI changes, please utilize this checklist:

• Make sure you use the API for UI elements that support large fonts.
• All colors are taken from WireDesign.ColorTheme or constructed using WireDesign.BaseColorPalette.
• New UI elements have Accessibility strings for VoiceOver.

[github-actions]

Test Results

86 tests   83 ✅  2s ⏱️
13 suites   3 💤
 1 files     0 ❌

Results for commit a281549.

♻️ This comment has been updated with latest results.

Summary: workflow run #23857699663
Allure report (download zip): html-report-28990-fix_crash-background-expiringactivity

[caldrian]

Could/should this go into release/cycle-4.17? @netbe

[typfel]

Doesn't this mean we are not waiting until the task has finished "cancelling" anymore and we'll instead immediately exit function and let the app suspend.

Couldn't this happen:

1. start expiring activity decrypting messages
2. activity expires and signal to cancel the decryption task
3. we exit the activity
4. crash because the decryption task didn't finish cancelling and therefore didn't have time to release the transaction lock.

[netbe]

@David-Henner since you added withTaskCancellationHandler I wonder if the PR still makes sense

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud