Anatomy of a positional-queue desync bug: why the visible half of a PR fix was a no-op

Short summary

A developer received a PR fixing a concurrency bug in their Safari MCP server's positional request/response queue, only to discover that the contributor's headline change was a no-op — behaviorally identical to existing code. The real fix was a quiet one-line splice in the catch block that removes the callback when a write fails, preventing a cascade where one broken-pipe error permanently desynchronizes the entire queue. The contributor correctly distinguished two opposite abandonment paths (timeout vs write failure) on their first try in code they didn't write.

• •PR's visible fix was behaviorally a no-op; the actual fix was a quiet splice in the catch block for write failures
• •A failed stdin write leaves an armed callback in a positional queue, causing a permanent cascade where every subsequent reply is consumed by the wrong waiter
• •The contributor correctly handled two opposite abandonment paths — keep the slot on timeout, remove it on write failure — without writing the original code

Generated with AI, which can make mistakes.