fix(transport): make ZmqTransport::Send actually retry

[nehalkpatel]

Fixes #30.

Two causes, not one

The issue's diagnosis was right that the retry path was unreachable, but there were two independent causes — and fixing only the timeouts would not have helped.

1. The timeout was never classified as retryable. cppzmq's send() reports an expired ZMQ_SNDTIMEO by returning an empty result, and throws error_t only for everything else (zmq.hpp:1967-1976). Send() looked for EAGAIN exclusively inside a catch block and treated the falsy return as a hard failure, so a send timeout came back as kOperationFailed and never reached the loop's deadline check at all.

2. The timeouts left no room, as reported. send_timeout bounds one attempt, retry.total_timeout bounds all of them, and both defaulted to 1000ms.

Changes

• TrySendOnce classifies one attempt as kSent/kWouldBlock/kFailed, catching the timeout in both forms ZMQ reports it. Send() is rewritten around that, and every exhausted path now returns kTimeout — a blocked PAIR socket means the peer never took the message either way.
• ClampSendTimeoutToRetryBudget(), called from the constructor, enforces max_attempts * send_timeout + (max_attempts-1) * retry_delay <= total_timeout by shrinking send_timeout and warning. It also floors max_attempts at 1, which otherwise skipped the loop entirely.
• Default send_timeout 1000ms → 300ms, so the defaults satisfy the invariant unclamped: 3×300 + 2×10 = 920ms ≤ 1000ms.

Clamping rather than rejecting the config: a caller asking for three attempts within a second has said something coherent, and the arithmetic that makes it fit is ours to do rather than grounds for failing startup.

A correction to the issue, and to the header

A peerless PAIR socket does not go mute, contrary to the issue's closing note and the header's own comments. connect() creates the outbound pipe whether or not the far end is reachable, and libzmq queues into it, so sends to nobody succeed until ZMQ_SNDHWM (1000) messages are outstanding. Measured directly. The stale comments are corrected here.

That is also why the tests below fill the queue rather than simply pointing at an unbound endpoint — the obvious setup would have passed against the broken code.

Tests

Two tests, each asserting the error, the retry count, and the elapsed time, so no single wrong answer satisfies all three:

• SendAttemptsEveryRetryWhenSocketBlocks — measured 326ms against a predicted 3×100 + 2×10 = 320ms.
• SendRetriesWhenSendTimeoutClaimsTheWholeBudget — the shape of the config that shipped. Measured 605ms against a predicted 3×193 + 2×10 = 599ms, bounded both ways so it distinguishes shortened attempts from full-length ones.

Against the unfixed code both fail, with kOperationFailed and zero retries.

Verification

cmake --workflow --preset=host-debug and --preset=host-release both green — 35/35 tests, including the Python integration suite. tools/format.sh --check clean; clang-tidy clean via the build.

🤖 Generated with Claude Code