A client team notices that a server's requestState looks like base64-encoded JSON containing a step counter. To save a round trip, their client decodes it, increments the counter, re-encodes it and sends it on the retry. The server now rejects those retries. What should the client do instead?
Select an answer to reveal the explanation.
Short Explanation
Treat requestState like a sealed envelope the server mailed to itself through you — you carry it, you don't steam it open. Even if it looks like plain base64, it's not yours to edit. The trap is assuming that because you can read it, you're allowed to change it.
Full Explanation
In the multi round-trip pattern, requestState is an opaque string meaningful only to the server. The client requirements are explicit: when an InputRequiredResult contains requestState, the client must echo back its exact value on the retry and must not inspect, parse, modify or make any assumptions about its contents. Servers, for their part, must treat requestState as attacker-controlled input and protect its integrity with something like an HMAC or AEAD when it influences authorization, resource access or business logic, then reject state that fails verification, which is exactly why the edited retries fail. Re-encoding with the same alphabet does not help, because integrity protection detects any change in content regardless of encoding. Dropping requestState breaks the server's ability to reconstruct the operation; the rule is that the client includes it whenever the server provided it, and omits it only when none was provided. Moving an edited counter into _meta is still client-side tampering with server state through a side channel and is not a defined mechanism. Exam caveat: a base64 encoding is a server choice, not a contract; the format can change at any time. Operational check: compare the requestState bytes in the InputRequiredResult with the retry and confirm they are byte-for-byte identical.