030de06618
Reconnecting is the documented way out of a connection the schedulers have stopped dispatching, and it was the only one of the four "try again" paths that didn't clear `consecutive_sync_failures`. Compare ConnectionController::sync, ConnectionController::update, AccountMappingController and the job's own success path — all reset to 0. So a user who reconnected a connection parked at MAX_SCHEDULED_RETRIES + 1 came back Active still carrying the count that parked it, and the first failure afterwards re-parked it immediately — none of the three attempts the ceiling is supposed to grant, right after paying the SCA redirect to escape exactly that state. It is also the one route by which a single out-of-band job death could reach the ceiling, which is what the previous commit closes from the other side. Both reviews found this independently while checking that commit's premise. |
||
|---|---|---|
| .. | ||
| Controllers | ||
| Middleware | ||
| Requests | ||
| Responses | ||