Collection: our own volume got connections to opendev dropped¶

Building the train and dev windows stalled twice against review.opendev.org. DNS was healthy throughout (16 timed lookups, none failed). Failed requests completed the lookup and never completed the TCP handshake, including with the address pinned. After hours of unpaced building, at about 20 requests a second, a quarter to a third of new connections were dropped. After 20 minutes of sending nothing, 0 of 30 were. Qt's server showed no such pattern.

Three changes to the transport, in order of discovery: one persistent connection per host with a 15-second timeout; a failed comments fetch dropping one change as comment_error instead of aborting the build (the diff fetch already had that guard); and a minimum interval between requests to one host, --request-interval, default 0.2 seconds. Changes lost to comment_error are counted in each month's drop profile, so collection loss stays auditable.

It is both servers, and 0.2 s is not enough. Qt's server did the same thing after about three hours of building: the process sat in SYN-SENT and an independent curl from the same box also timed out, which is the opendev signature exactly. So this is not one operator's policy but what a community Gerrit does to a client that sustains requests for hours, and the 0.2-second interval (5 requests a second) only postponed it.

The build was stopped rather than left to run. Its retries would have exhausted and dropped changes as comment_error, which is counted and therefore auditable, but a final month carrying hundreds of such drops would differ materially from the other twelve, and that month feeds the dev window that censoring has already thinned. Twelve of thirteen months were already written, so the cost was one month's fetching.

Qt's block outlasts the traffic; opendev's did not. After 25 minutes of sending nothing, 10 of 12 probes to Qt still failed, where opendev had recovered fully (0 of 30) after 20. It is Qt-specific rather than local: in the same minute opendev, GitHub and Google answered 5 of 5 while Qt answered 1 of 5. That shape, a refusal that persists after the load stops, reads as a firewall ban rather than load shedding, so waiting is the only remedy and the interval that avoids it has to be well below the 5 requests a second that triggered it.

What it costs, which is less than it looks. Qt's twelve built months are 2024-10 through 2025-09, so the pilot window (2024-10) and the whole train window (2024-11 to 2025-08) are complete. Only 2025-10 is missing, which is the second of the dev window's two months. Training is therefore unaffected for both organizations; Qt's dev window is half size, which widens its intervals and is stated wherever its numbers appear.

Measuring how the sampling window fooled me. Reading the build's bytes over 5 seconds showed zero and looked like a stall; over 60 seconds it read 2.6 MB and was healthy. A paced, bursty client needs a sampling window longer than its retry backoff (1+2+4+8+16 = 31 s) before "no progress" means anything. Both readings were reported before the longer one corrected them.