the retry worker and the gone retry requeue a repo by deleting its resync entry, and that entry was the only place retry_count lived. so the next failure started over at 1 and next_backoff never got past about 2 minutes, and a repo whose pds keeps failing getRepo was refetched every couple of minutes forever instead of backing off toward an hour. a failure now reads the count from the repo's metadata, which survives the requeue, writes the next count to both the metadata and the resync entry (where /repos shows it), and a backfill that stores the repo sets it back to 0. requeueing also carries over the count an entry from before v14 holds. the resync entry and the pending key still never coexist, so the gauge, the retry worker and /repos see the queue the same way. backoff_grows_across_requeues_until_a_fetch_succeeds runs seven failures through the real requeue and checks the count and the wait (2, 4, 8, 16, 32, 60, 60 minutes), then a good car resets it. without reading the count from the metadata it fails at the second failure with retry_count 1.