If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
### 💡 Codex Review
Here are some automated review suggestions for this pull request.
**Reviewed commit:** `e31e2d5be7`
<details> <summary>ℹ️ About Codex in GitHub</summary>
<br/>
[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
</details>
Keep the first-probe wait on the advertised timeout
Once the synchronization signal is deferred to this first-reply path, the socket's 500 ms read timeout becomes the real deadline rather than the receiver's stated 2 seconds. On a loaded Unix CI worker, the CLI can complete OPEN but be descheduled for more than 500 ms before sending its first probe; recv_request_timeout then exits, drops this sender, and both interruption tests panic even though their explicit synchronization timeout has not elapsed. Retain the longer timeout until the first probe/reply has been observed, then shorten it for shutdown cleanup.
**<sub><sub></sub></sub> Keep the first-probe wait on the advertised timeout**
Once the synchronization signal is deferred to this first-reply path, the socket's 500 ms read timeout becomes the real deadline rather than the receiver's stated 2 seconds. On a loaded Unix CI worker, the CLI can complete OPEN but be descheduled for more than 500 ms before sending its first probe; `recv_request_timeout` then exits, drops this sender, and both interruption tests panic even though their explicit synchronization timeout has not elapsed. Retain the longer timeout until the first probe/reply has been observed, then shorten it for shutdown cleanup.
AGENTS.md reference: [AGENTS.md:L125-L130](https://github.com/Lochnair/irtt-rs/blob/e31e2d5be778dc842f56c53062d69a60931382f7/AGENTS.md#L125-L130)
Useful? React with 👍 / 👎.
Fixed: the socket now keeps the longer (2s-bounded) read timeout until it actually receives the first probe, and only shortens to 500ms afterward to bound the post-interrupt shutdown wait. See 1f44f26.
Fixed: the socket now keeps the longer (2s-bounded) read timeout until it actually receives the first probe, and only shortens to 500ms afterward to bound the post-interrupt shutdown wait. See 1f44f26.
_🤖 Addressed by [Claude Code](https://claude.com/claude-code)_
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
### 💡 Codex Review
Here are some automated review suggestions for this pull request.
**Reviewed commit:** `99043444a1`
<details> <summary>ℹ️ About Codex in GitHub</summary>
<br/>
[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
</details>
When the fake-server thread wins scheduling after send_to, this signal only proves that the UDP datagram was queued by the server, not that the managed client received and emitted it. The test thread can therefore send SIGINT before the client processes the reply, causing continuous_single_target_interruption_drains_final_events_and_succeeds to close without the required echo_reply row and fail nondeterministically. Synchronize on a client-observable event, such as reading that output row, before interrupting.
**<sub><sub></sub></sub> Wait for the client to consume the first reply**
When the fake-server thread wins scheduling after `send_to`, this signal only proves that the UDP datagram was queued by the server, not that the managed client received and emitted it. The test thread can therefore send SIGINT before the client processes the reply, causing `continuous_single_target_interruption_drains_final_events_and_succeeds` to close without the required `echo_reply` row and fail nondeterministically. Synchronize on a client-observable event, such as reading that output row, before interrupting.
AGENTS.md reference: [AGENTS.md:L125-L128](https://github.com/Lochnair/irtt-rs/blob/99043444a1d2c3cefc183ddc91627029acb1c1d3/AGENTS.md#L125-L128)
Useful? React with 👍 / 👎.
Not changing the synchronization here: gating SIGINT on reply-sent (rather than client-consumed) is intentional — this test specifically covers the case where a reply is still in flight/queued at interrupt time, and the echo_reply assertion proves shutdown drains it instead of losing it. Waiting for client-side consumption first would remove that scenario entirely. Added a comment (78151ff) documenting this so it's not mistaken for a race next time.
Not changing the synchronization here: gating SIGINT on reply-sent (rather than client-consumed) is intentional — this test specifically covers the case where a reply is still in flight/queued at interrupt time, and the `echo_reply` assertion proves shutdown drains it instead of losing it. Waiting for client-side consumption first would remove that scenario entirely. Added a comment (78151ff) documenting this so it's not mistaken for a race next time.
_🤖 Addressed by [Claude Code](https://claude.com/claude-code)_
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:
e31e2d5be7ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Once the synchronization signal is deferred to this first-reply path, the socket's 500 ms read timeout becomes the real deadline rather than the receiver's stated 2 seconds. On a loaded Unix CI worker, the CLI can complete OPEN but be descheduled for more than 500 ms before sending its first probe;
recv_request_timeoutthen exits, drops this sender, and both interruption tests panic even though their explicit synchronization timeout has not elapsed. Retain the longer timeout until the first probe/reply has been observed, then shorten it for shutdown cleanup.AGENTS.md reference: AGENTS.md:L125-L130
Useful? React with 👍 / 👎.
Fixed: the socket now keeps the longer (2s-bounded) read timeout until it actually receives the first probe, and only shortens to 500ms afterward to bound the post-interrupt shutdown wait. See 1f44f26.
🤖 Addressed by Claude Code
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:
99043444a1ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
When the fake-server thread wins scheduling after
send_to, this signal only proves that the UDP datagram was queued by the server, not that the managed client received and emitted it. The test thread can therefore send SIGINT before the client processes the reply, causingcontinuous_single_target_interruption_drains_final_events_and_succeedsto close without the requiredecho_replyrow and fail nondeterministically. Synchronize on a client-observable event, such as reading that output row, before interrupting.AGENTS.md reference: AGENTS.md:L125-L128
Useful? React with 👍 / 👎.
Not changing the synchronization here: gating SIGINT on reply-sent (rather than client-consumed) is intentional — this test specifically covers the case where a reply is still in flight/queued at interrupt time, and the
echo_replyassertion proves shutdown drains it instead of losing it. Waiting for client-side consumption first would remove that scenario entirely. Added a comment (78151ff) documenting this so it's not mistaken for a race next time.🤖 Addressed by Claude Code