e0481df497
Every `logSyncAttempt` call lived inside `handle()`, which is exactly what an out-of-band death skips — so a connection's own history showed no trace of the most common way this job dies. One prod connection has 66 job failures and 3 sync-log rows. That gap is why the first pass of this branch mis-attributed the stranding to timeouts: the evidence was only in `failed_jobs`. `duration_ms` becomes nullable at the call site rather than being faked to 0, because nobody timed the attempt. The copy changes too. `failed()` wrote "An unexpected error occurred during sync. Please try again later." — handing our own infrastructure to the user as an action — while the classified-transient path already promised "we will try syncing again later" for the same situation. Every message this method writes describes an out-of-band death, so it now says so and the next scheduled cycle picks the connection back up on its own. |
||
|---|---|---|
| .. | ||
| en | ||
| es | ||
| fr | ||
| en.json | ||
| es.json | ||
| fr.json | ||