Why must a persisted-operation manifest reach the server before the client build that uses it ships?

## The identifier is a promise the server must already be able to keep Give a client an identifier and it will send it. Whether that works depends entirely on whether the server can resolve it, and a build-time registry offers no negotiation: the client cannot supply the document text it is referring to, because the build removed that text from the artefact. That makes late publication a **total** failure, not a degraded one. It is not that some fields go missing or some operations run slowly; every operation from that client version, for every user on it, comes back as an unresolvable identifier from the moment the version is reachable until the manifest lands. There is no partial success to mask it, and usually no retry that helps, because a retry sends the same unknown key. A concrete shape for the incident: the freight console's bundle reached its CDN at 14:07 and the pipeline's manifest-publish step ran at 14:11. Every scan, every consignment lookup and every dispatch confirmation attempted in those four minutes failed — from a change nobody had made to the schema, the resolvers, or the client's logic. The postmortem is about job ordering. ## The ordering that follows Publish the manifest. Confirm the server can read it. Then release the client. In pipeline terms the publish is a **gate**, not a step: the release job writes the manifest, reads it back through the same path a request would use, and only flips the client artefact live once that read-back succeeds. Failing a deploy because the manifest is unreadable is cheap; the alternative is a failure window whose length is whatever the timing between two unrelated jobs happens to be. Two details decide whether that ordering actually holds in production. **Where the registry lives.** If the manifest is baked into the server image and loaded at boot, then "published" is not a moment — it is the duration of a rolling deploy. During the roll some instances hold the new entries and some do not, so a client released in that window fails on a fraction of its requests and succeeds on the rest. That is worse than a clean outage, because intermittent failure reads as flakiness and sends people looking at the network. Publishing to a store every instance reads — with a refreshable cache rather than a boot-time load — turns the roll back into a single event. **Whether the registry is cumulative.** A registry is a union of everything still reachable, not a snapshot of the current build. If the publish step replaces the contents, a server rollback restores an older manifest and un-publishes identifiers that live clients are still sending — the same total failure, arriving during the change that was meant to end an incident. Entries are added, and much later retired deliberately; they are never dropped as a side effect of a deploy. ## "The client ships" is not a moment either Even on the web, releasing a new bundle does not retire the old one. Users hold cached bundles, long-lived tabs keep running the code they loaded this morning, and a CDN may serve the previous artefact until its entry expires. So the union has to span the versions that are actually reachable, not the version you most recently built. Rolling a web client *back* has the same trap in reverse: the older bundle's identifiers must still be in the registry — which they will be, if nothing ever removes entries on deploy. An installed application makes this dramatically worse, because you cannot withdraw it at all. The publish-first rule is unchanged, but the tail stretches from minutes to months, which converts the ordering problem into a retention problem. ## What the client sees, and what to do with it The response to an unknown identifier is not specified. Servers vary between a request error inside the GraphQL envelope — an `errors` entry and no `data` key, since nothing executed — and a plain HTTP 4xx with no envelope at all. Either way it is worth pinning as a distinct case in the client, because the correct handling is not the handling for a failed field. A retry will not help; a background refresh will not help. The situation is "this build cannot talk to this server", and the useful responses are a forced reload for a web client or an upgrade prompt for an installed one. Interviewers like this question because the answer is barely about GraphQL. It is about a coupling between two artefacts that are normally deployed independently, and about noticing that a scheme which removes text from requests has also removed the client's ability to recover on its own.