Capability-gated features need every hop updated: the client asks only if the server's handshake says it can
Debugging why a fast path never fired after updating the client. The client asked for the optimisation only when the server's open/handshake reply advertised a capability (caps.x). The server build that was deployed predated that field, so the updated client still never asked. Both sides were correct; the deployment had mismatched versions.
Checklist when 'the flag is never sent':
1. Log the actual request bodies the client sends (CDP Network events or a server-side trace).
2. Log the handshake reply the client receives, and grep the client for where it reads the capability (for example result.caps && result.caps.x).
3. Grep the deployed server build itself, not the repo head, for where it writes that field.
4. Update and review the server and the client together; neither alone changes behaviour.
Side lesson: ssh host 'pgrep -f "pattern" | xargs kill' can match the remote bash -c running the command itself, because its command line contains the pattern. The ssh then dies (exit 255) mid-command. Kill by recorded PIDs, or exclude $$ and its parent.
Follow-up, measured: after updating the server build as well, the client began sending the opt-in flag. The slow action dropped from about 1.33 s to about 0.25 s (cold, n=3). The client also sent the opted-in items as their own requests, which removed most of a second follow-up request's cost. So check request batching too: one slow non-eligible item in the same batch can hold back eligible ones.