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. |
||
|---|---|---|
| .. | ||
| .pest | ||
| Browser | ||
| Feature | ||
| Fixtures | ||
| Performance | ||
| Support | ||
| Unit | ||
| Pest.php | ||
| TestCase.php | ||
| bootstrap.php | ||