We use cookies to understand how the site is used and to improve it. You can accept them, or carry on with them switched off.
Also known as: outdated headers, stale headers
A locally cached group index that no longer matches the server's article numbering, producing 423 responses when the client requests numbers that have since expired. Header-based readers left unrefreshed for weeks list articles that cannot be fetched. Resetting or re-downloading headers for the group realigns it. Indexers sidestep the problem entirely by listing releases with message-ids instead of per-server article numbers.
The misunderstanding underneath this failure is that article numbers look like stable identifiers and are not. Every server assigns its own sequential number to each article within each group as it arrives, and two servers carrying the same article will hold it under different numbers. A number is meaningful only as a triple: one group, on one server, at one time. Change any of the three and it refers to nothing.
Numbers only increase, so the high end of the range moves forward continuously as articles arrive. The low end moves as well: as articles pass the server's retention window or are removed, the low water mark advances, and every number below it is gone from that server permanently. A GROUP command returns the current low and high water marks along with an estimated article count, which is how a client learns where the range currently sits. A cached index built weeks earlier describes a range that has shifted underneath it in both directions.
The reader displays a full subject list, the articles appear to be present, and requesting the older ones returns 423, no article with that number in this group. Newer articles in the same group fetch normally, which makes the fault look intermittent and invites the conclusion that the provider is unreliable. The distinguishing detail is the distribution: failures cluster at the old end of the list rather than scattering through it. Scattered failures across all ages point at missing articles or an incomplete post, which is a different condition entirely.
Aiming an existing local index at a different server invalidates the numbering completely, because the second server's numbers for that group bear no relation to the first server's. This includes switching to a backup server already configured in the same client and moving an account between providers on different backbones. The result is failures across the whole range rather than only at the old end, which is the quickest way to tell the two situations apart. A newsreader that keeps one index per group rather than one per group per server cannot represent both at once, so a change of server calls for a rebuild.
The fix is to discard the cached headers and fetch them again, exposed by newsreaders as resetting, purging, or refreshing a group. Doing it group by group is considerably faster than a full reset when only one or two are affected. For a busy binary group the header download itself can be substantial, which is why most readers offer a setting limiting how many recent headers to retrieve rather than fetching the entire retained range.
An NZB lists Message-IDs, which are globally unique and server independent, so the same NZB works against any server that still holds the articles and nothing needs rebuilding when the server changes. This is the practical reason header-based reading persists mainly in text groups, where header volumes are small and the index is cheap to rebuild, while binary retrieval moved to Message-ID lists.
Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.