You push a new configuration to a running Envoy and the proxy keeps serving the old one. Explain how Envoy's xDS ACK/NACK works — version_info, the nonce and error_detail — and how you would confirm the update was rejected.

## The request/response loop An xDS subscription is a long-lived bidirectional gRPC stream, and it is chattier than "server pushes, client obeys". Every push is acknowledged. Envoy opens with a `DiscoveryRequest` naming the `type_url` it wants, the `resource_names` (for by-name types), an empty `version_info` and an empty `response_nonce` — meaning "I have nothing, send me everything". The server replies with a `DiscoveryResponse` containing the resources, an opaque `version_info` string of its own choosing, and a `nonce` unique to this response. Envoy then validates and applies, and sends another `DiscoveryRequest` on the same stream. That request is both the acknowledgement of the previous response and the standing subscription. Two fields make it an ACK or a NACK: - `response_nonce` — always the nonce of the response being answered. This is how the server matches an acknowledgement to a specific send, which matters because it may have pushed several times before hearing back. - `version_info` — the version Envoy is *now* running. **ACK:** `version_info` = the version from the response just received, `error_detail` unset. **NACK:** `version_info` = the last version Envoy successfully applied (or empty, if it never applied one), plus `error_detail` — a `google.rpc.Status` whose message is the validation failure. So the wire signature of a rejection is a version that did not advance. There is no "reject" message type; the version regression *is* the rejection. ## Rejection is per-response, not per-resource This is the part candidates get wrong and the part that bites in production. In State-of-the-World xDS, the unit of acceptance is the entire response for that type. If a push contains 400 clusters and one has an invalid field, Envoy rejects all 400 and keeps the ones it had. Nothing partially applies. The consequence is that a small, obviously-safe change can be blocked by an unrelated defect elsewhere in the same resource type — a config generated for a different service, sharing your CDS push, refuses to validate, and your change silently never lands. It never lands for *every* proxy subscribed to that push, which is why one bad resource can freeze configuration fleet-wide while every proxy continues serving traffic perfectly. (Delta xDS narrows this: rejection is still per-response, but responses carry only changed resources, so a bad resource blocks a much smaller batch.) ## What the proxy does meanwhile Nothing dramatic, and that is by design. A NACKing Envoy keeps its last accepted configuration and keeps serving traffic on it. The data plane is fail-static: bad input does not take it down, it just stops it moving. That property is what makes the symptom "my change didn't take effect" rather than "the site is down", and it is also why the failure can sit unnoticed for hours. The stream itself stays up. Envoy does not disconnect on a NACK, and a well-behaved management server does not either — it takes the `error_detail`, ideally surfaces it, and waits for someone to push a version that validates. ## Confirming it Work the two ends: **On the proxy.** Envoy logs the rejection with the validation message — usually the fastest read, because the message names the offending field. Its xDS subscription stats include an `update_rejected` counter alongside `update_success` and `update_attempt`; a rising `update_rejected` with a flat `update_success` is the signature, and `control_plane.connected_state` tells you separately whether the stream is even up. Dumping the proxy's effective configuration tells you what it is actually running, which settles "did it apply and not work" versus "it never applied". **On the control plane.** The server received `error_detail` and knows which node sent it. Most implementations expose per-proxy sync status; that is where you learn that 3 of 900 proxies are stuck two versions behind, and why. ## Why versions are opaque `version_info` is a string the management server invents. It is not a counter Envoy interprets and not something you can compare for ordering — the only thing Envoy does with it is echo it back. The pairing with `nonce` exists to disambiguate in-flight work: versions identify *state*, nonces identify *a particular send of that state*. If a server pushes v7, then v8 before the v7 acknowledgement arrives, the nonces let it tell which one the incoming acknowledgement refers to; without them, a stale ACK for v7 could be misread as acceptance of v8. ## The mistake to avoid making out loud Do not say Envoy "rolls back" on a NACK. There is no rollback: the new configuration was never applied, so there is nothing to undo. Envoy validated it, refused it, and continued with what it already had. The distinction matters because rollback implies a window in which the bad config was live, and there is none.