React Native uploads need a database row and a native session to outlive the lock screen

Six state names carry most of the design: pending, uploading, uploaded, processing, ready, failed ^[5]. Comments in the store matter more than the names. `uploaded` means the bytes are on the server; `processing` means the server is transcoding ^[5]. The recovery query, `unfinished()`, selects rows in pending, uploading, uploaded or processing, which is four of the six, leaving ready and failed as the only terminal states ^[6][13]. Two of those four describe work the client is not performing ^[14]. The resume path is not a retry loop but a question put to the server about an id the client wrote down before the transfer began ^[18].

That asymmetry exists because the client has no way to learn it lost. iOS suspends the process, Android may reclaim it, and neither OS lets JavaScript keep a transfer alive ^[3]. The promise never settles: no rejection, no catch, and a fresh runtime when the user returns ^[1]. A frozen progress bar is the most honest widget in the app, since it reports exactly what the JS runtime knows, and the runtime knows nothing ^[4].

The handoff to native is where the config lines prove the point. `path` is `localUri.replace('file://', '')`, because iOS wants a bare path ^[12], and the payload has to be written to a file with a normalised path first, since iOS needs a URL it can still read after your process is gone ^[7]. The notification block is load-bearing rather than cosmetic: enabling it is what ties the Android transfer to a dataSync foreground service ^[12].

That service's window comes with a condition. The dev.to walkthrough cites Google's guidance that a dataSync service started from direct user interaction gets the full window once the app backgrounds, and that the budget resets when the user next foregrounds the app ^[8]. Read it as a constraint on retries: an automatic retry fired while the app is already backgrounded has no such guarantee, so retry scheduling belongs on the next foreground pass ^[15]. On Android 14 and below there is no timeout callback to hang recovery off in any case, which leaves the foreground reconcile as the only trigger worth trusting ^[19].

The source is a code walkthrough with a reproduction recipe, roughly 150 lines, not telemetry on how often suspension eats an upload in production ^[17][2]. For the pattern to transfer to your stack, your server must report per-asset status for an id the client generated, because `asset_id` is nullable at insert time and the client holds only its own primary key until the server answers ^[18], and your upload URL must survive the gap, because the schema stores `upload_url` and replays it on resume, though the walkthrough does not address presigned expiry ^[16].

If your API only reports success at the moment the PUT returns, the reconcile step has nothing to ask, and the persisted row is decoration.