GaCy-GO/docs/currency-wars-response-boundary.md

CW typed response boundary

Source correction, 2026-10-25

The shared typed dispatcher sends its response only when the registered function returns nil (or the handler has already sent the response explicitly). Several CW paths returned resource, validation or save errors directly. Those paths therefore left the Client waiting instead of receiving the revision's typed error response.

CW registrations now use cwHandle / cwHandleNamed, which still resolve request and response IDs by their names through the existing protocol table. When a CW operation returns an application error, the wrapper preserves a nonzero retcode already selected by that handler, or assigns RET_GRID_FIGHT_CONF_MISS if it was still zero. It logs the error and returns control to the dispatcher to send exactly one typed response. It never converts an unsupported operation into success or replays a failed transaction.

Every explicit packet send within these registered handlers uses cwSend to mark any send error, including serialization or projection failures. The wrapper propagates that error, network/EOF/closed-connection errors, and errResponseAlreadySent unchanged. It does not attempt an additional packet in those cases. The former pending-action-specific error defer was removed because it swallowed send errors as though they were application failures.

GridFightUpdatePos also rejects position changes while CURRENT_BATTLE is active, matching the existing Preparation-only mutation boundary used by shop, equipment and grants. This does not remove or settle the active battle.

Validation and limits

• go build ./internal/gameserver succeeded. No tests were run.
• No executable was replaced, no server restarted, no live save changed and no probe was staged by this change.
• This closes a source-level missing-response path. Client behavior is not yet verified, and Tea Break choices, automatic Orb drops/opening and later route recipes are still incomplete.
• The existing GridFightEnterBonfire handler's success-only navigation response is not proof of a working Tea Break. Its game-event consumer and the associated current revision's choices/effects still need runtime evidence before new pending state can be implemented.

The static inventory scanner recognizes both CW wrappers, so registration reports continue to distinguish present handlers from actual gameplay support.