Retry Loop

The loop is expensive in a way that is easy to overlook, because the client presents it as activity. Connections show as busy, counters move, and a trickle of traffic appears on the graph from command responses. What is absent is progress: the same message-ids are being requested from the same spool that did not hold them a moment earlier. Fault is split here, and cleanly. Whether an article exists belongs to the provider. How long a client insists on asking for one that does not belongs to the configuration on the local machine.

What the loop consumes

Metered bandwidth is not the casualty. A 430 response carries no body, so a block account loses almost nothing measurable. The real costs are connection slots, each retry occupying one of the account's allowed sessions while it waits; time, since an article retried ten times across four servers is forty request round trips for a segment that was never going to arrive; and queue position, because jobs behind the stuck one wait for capacity that is being spent on a foregone conclusion.

Why repeating the request cannot succeed

Presence on a spool is a static fact over the intervals a client works in. A 430 means that message-id is not in that server's storage, and storage does not repopulate itself in response to being asked again. Two narrow exceptions exist. An article posted minutes ago may still be propagating, where a short wait genuinely changes the answer. A load-balanced cluster can briefly return an inconsistent result between nodes. Both are matters of minutes, not of the hours a runaway retry setting will spend.

Settings that produce it

• Article retry limits above two or three. Higher values were useful when propagation was slower and are now mostly a way to convert a fast failure into a slow one.
• A long Server priority chain in which several entries share a backbone, so the same absent article is requested repeatedly from what is effectively one spool.
• Automation that re-grabs the same release each time a job fails, producing an outer loop around the inner one that no client-side retry setting can break.

The intended path is the opposite of persistence. Failed articles should fall through quickly so that PAR2 recovery blocks can reconstruct what is missing, which is the mechanism designed for exactly this situation and which works on data already downloaded rather than on requests to a server.

Telling it apart from congestion and from a stall

Three states look similar in a status panel and are distinguished by two counters. A congested or throttled server delivers bytes slowly but does deliver, so the completed figure climbs. A stall shows no counter moving at all. A retry loop shows failed-article counts climbing steadily while completed bytes stay flat. The client's log settles it: repeated 430 responses against the same message-id, from more than one server entry, is the loop and nothing else. A single article reported as not found, once, is ordinary and needs no action at all.