A 402 Front Door Is Not an Upstream

On November 7, 2026, the operational notes revealed that the catalog count at a marketplace dropped by three listings overnight. There was no deploy, no error spike, and no reports. Three third-party listings had active=0, and all obvious explanations were incorrect: no deregister request in the gateway log, no rows in delivery_outcomes, and no open reports. The rows were removed by the daily sweep for a reason that nobody could read afterward, including the sellers.

Two key points emerged from the situation. First, the challenge was not caused by the seller but by the marketplace. The probe data displayed contradictions, with the same rows showing status: payment_required, http_code: 402, latency_ms: 14, error: null, and upstream: unreachable. The marketplace's edge emitted a challenge, while the seller's endpoint responded with a 402 status code.

The 402 status code was generated before any forwarding, indicating that the marketplace's measurement was accurate, regardless of the seller's endpoint health.

Second, the phrase "didn't ask in time" did not mean the listing was dead. Various connection errors, DNS deadlines, HTTP 404 errors, and declared methods the endpoint refused were different claims. Only some of these justified removal. The marketplace's probe separated these claims and excluded the last one from the delist rule, as it was a metadata bug rather than a dead service. When the probe combined these claims into one boolean, a typo in a description would result in removal.

A notable aspect was the listing disappearing from the seller's side. The only surface for a submitter to read the state of their row was a signed call that returned it along with a free-text note, which was empty. The row showed active: false and nothing else. The marketplace updated the sweep to write the reason into the note when it removed something and stopped pretending that it only touched first-party routes. The sweep judged one field, which was not filtered by who owned the row.

The marketplace implemented this change to ensure it could provide a reason for removal and a way back for the listing. No automatic resurrection was built, as it would bypass the review gate for every new listing and make it difficult to distinguish removal caused by the uptime sweep from removal caused by a human for a reason.

The end state after the fix and a review pass over the pending queue showed 1,842 live listings, with three removed, 12 approved, 3 rejected as duplicates, and 10 held due to unmeasurable hosts. The four counting surfaces – the API catalog, MCP tool list, well-known manifest, and page counters – agreed at 1,851 live listings.