[danseethaler]

What could go wrong

On iOS, a retry's backoff exists only as the begin date of a background task: the library creates the next attempt right away and lets nsurlsessiond hold it until the date. If the daemon refuses the app's connection, that task fails immediately with NSURLErrorDomain -1, before its begin date and without sending anything. The library counted that as a transient failure and created the next delayed task at once, which failed the same way.

That loop ran at 300–600 attempts a second, each writing the entry and opening a new XPC connection. The app sat at about 200% CPU and grew to gigabytes of memory. We hit it on two simulators running diana's CI dev builds, which had no entitlements, so the daemon logged "does not have a bundle ID, rejecting connection" for every session. That build is fixed in openspacelabs/diana#9825. The library should still not spin when the daemon says no.

What this PR does

• A refused delayed task isn't an attempt. A delayed task that ends before its begin date, with no response and no bytes sent, never reached the daemon. It emits no event and keeps its ordinal and request id. The app waits out the rest of the delay itself, then issues the attempt again (advanceAttempt: false). All three conditions are needed, so a clock change during the wait can't turn a real failure into this. The error code isn't checked, because -1 also comes with real failures.
• Chunked parts get the same treatment. A refused part task keeps its begin date and refills once the date passes. Unlike a simple request, the refilled part still takes a new ordinal, as every part task does.
• A floor as a backstop, simple requests only. A retry never starts within baseMs of the previous attempt's start. One that ended before its own start gets no task for baseMs. The floor lives in memory only.
• TaskCompletion carries bytesSent (from countOfBytesSent) so the completion path can tell.

Android doesn't have this flaw: it waits out the backoff itself before making the request.

Review notes

• System cancels change slightly. If iOS cancels a delayed task before its begin date with nothing sent, the library now waits out the delay under the same ordinal, instead of minting a new attempt with a fresh backoff. It never ran, so that seems right.
• Four existing tests now advance the fake clock before completing a delayed task. They delivered a server response before the task's begin date, which the real daemon can't do, and that tripped the floor.
• Conflicts with Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69 and Do not reject settings calls when the settings file cannot be saved #72 in QueueCoordinator+Outcomes.swift. It's small: one added line, attemptStarts[id] = nil, next to code Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69 rewrites. Build iOS part tasks in slices so the next mutate() does not wait #70 and Release v9 bytes no row owns, and reuse the v9 blob on a replace #65 merge cleanly with this branch and pass the suite (293 and 272 tests).

How it was tested

• swift test in ios/: 263 tests, 0 failures, 5 new. They cover every task refused for 10 s of fake time (bounded attempts, no tight loop), one refused task keeping its ordinal and X-Request-Id, a task failing after its begin date still counting, a task that sent bytes or got a 503 early still counting, and a refused chunked part. With the fix disabled the new tests fail.
• In diana on an iPhone 15 simulator, with this branch in node_modules and the app built with CODE_SIGNING_ALLOWED=NO, so the daemon refuses it:
  • A stuck upload went from about 5,500 attempts per 30 s to 1 attempt per backoff.
  • Two new uploads backed off with growing gaps (about 14 s, 32 s, 74 s).
  • CPU stayed under 2%.
  • With v11.1.0 the same build spun at 199% CPU.
• No JS changed, so yarn lint:ci, typecheck and test weren't run.

🤖 Generated with Claude Code

[arnonate]

does @dmurphy5's work conflict with this at all or will this slide in as an addition?

[arnonate]

From claude:

Mostly it slides in as an addition. I trial-merged Dan’s branch (openspacelabs/react-native-background-upload#80) against master and each of Dylan’s ten open PRs. Seven merge cleanly and three conflict, all of them small:

Dylan’s PR | Result with #80 -- | -- #69 storage cause | Conflict in ios/QueueCoordinator+Outcomes.swift #72 settings never reject | Same conflict, because it’s stacked on #69 #79 entry save durability | Conflict in CHANGELOG.md only #65, #67, #70, #71, #74, #76, #78 | Clean

• Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69 and Do not reject settings calls when the settings file cannot be saved #72: Dan adds one line, attemptStarts[id] = nil, at the end of the settle function. Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69 rewrites the end of that function and drops the return true beside it. Whoever merges second keeps Dan’s line and Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69’s version of the ending. Dan already calls this out in his review notes.
• Keep a new iOS request when a power loss undoes its entry save #79: both PRs add a changelog entry in the same spot. Keep both.

A clean merge doesn’t prove the result compiles. Dan adds a required bytesSent field to TaskCompletion, so any other PR that builds one needs the new argument. Of Dylan’s PRs, only openspacelabs/react-native-background-upload#70 touches that area, and it changes many of the same iOS files. Dan’s PR says openspacelabs/react-native-background-upload#70 and #65 pass the test suite when combined with his branch. I didn’t run the suite on any combination myself, so the other clean merges are untested beyond the text merge.

Merge order doesn’t matter much. If #80 goes first, Dylan resolves the one-line conflict when he rebases openspacelabs/react-native-background-upload#69.

Mostly it slides in as an addition. I trial-merged Dan’s branch ([#80](https://github.com//pull/80)) against master and each of Dylan’s ten open PRs. Seven merge cleanly and three conflict, all of them small:

Dylan’s PR Result with #80
openspacelabs/react-native-background-upload#69 storage cause Conflict in ios/QueueCoordinator+Outcomes.swift
openspacelabs/react-native-background-upload#72 settings never reject Same conflict, because it’s stacked on #69
openspacelabs/react-native-background-upload#79 entry save durability Conflict in CHANGELOG.md only
#65, #67, #70, #71, #74, #76, #78 Clean
#69 and #72: Dan adds one line, attemptStarts[id] = nil, at the end of the settle function. #69 rewrites the end of that function and drops the return true beside it. Whoever merges second keeps Dan’s line and #69’s version of the ending. Dan already calls this out in his review notes.
#79: both PRs add a changelog entry in the same spot. Keep both.

A clean merge doesn’t prove the result compiles. Dan adds a required bytesSent field to TaskCompletion, so any other PR that builds one needs the new argument. Of Dylan’s PRs, only openspacelabs/react-native-background-upload#70 touches that area, and it changes many of the same iOS files. Dan’s PR says openspacelabs/react-native-background-upload#70 and #65 pass the test suite when combined with his branch. I didn’t run the suite on any combination myself, so the other clean merges are untested beyond the text merge.

Merge order doesn’t matter much. If #80 goes first, Dylan resolves the one-line conflict when he rebases openspacelabs/react-native-background-upload#69.