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:** `61ed029988`
<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>
For a target receiving at least 65,537 replies, VecDeque's geometric growth increases this buffer's capacity from 65,536 to 131,072; push_bounded later limits its length to 100,000 but never releases the 31,072 excess slots. Long-running active targets therefore retain more graph-history heap than the previous exact-limit allocation, with the overhead multiplied in multi-target runs, so grow the queue in capped increments or reserve only the final remainder as it approaches HISTORY_LIMIT.
**<sub><sub></sub></sub> Cap lazy growth at the history limit**
For a target receiving at least 65,537 replies, `VecDeque`'s geometric growth increases this buffer's capacity from 65,536 to 131,072; `push_bounded` later limits its length to 100,000 but never releases the 31,072 excess slots. Long-running active targets therefore retain more graph-history heap than the previous exact-limit allocation, with the overhead multiplied in multi-target runs, so grow the queue in capped increments or reserve only the final remainder as it approaches `HISTORY_LIMIT`.
AGENTS.md reference: [AGENTS.md:L53-L58](https://github.com/Lochnair/irtt-rs/blob/61ed029988b39caec1b7fad1850c038c01ac4a06/AGENTS.md#L53-L58)
Useful? React with 👍 / 👎.
Test the allocation bound instead of exact zero capacity
A future implementation could reserve a small initial buffer while still avoiding the problematic HISTORY_LIMIT preallocation, but this exact-capacity assertion would reject it despite preserving the intended memory invariant. Assert the meaningful upper bound, or remove/consolidate this test, rather than pinning VecDeque's private allocation mechanism.
**<sub><sub></sub></sub> Test the allocation bound instead of exact zero capacity**
A future implementation could reserve a small initial buffer while still avoiding the problematic `HISTORY_LIMIT` preallocation, but this exact-capacity assertion would reject it despite preserving the intended memory invariant. Assert the meaningful upper bound, or remove/consolidate this test, rather than pinning `VecDeque`'s private allocation mechanism.
AGENTS.md reference: [AGENTS.md:L104-L106](https://github.com/Lochnair/irtt-rs/blob/61ed029988b39caec1b7fad1850c038c01ac4a06/AGENTS.md#L104-L106)
Useful? React with 👍 / 👎.
Removed the test — swapped for a plain upper-bound assertion (capacity() < HISTORY_LIMIT + HISTORY_LIMIT / 10) added to echo_reply_appends_bounded_primary_history instead of pinning VecDeque's private allocation mechanism.
Removed the test — swapped for a plain upper-bound assertion (`capacity() < HISTORY_LIMIT + HISTORY_LIMIT / 10`) added to `echo_reply_appends_bounded_primary_history` instead of pinning `VecDeque`'s private allocation mechanism.
_🤖 Addressed by [Claude Code](https://claude.com/claude-code)_
Fixed in push_bounded: once capacity reaches half of limit, we now reserve_exact up to limit instead of letting the next geometric doubling overshoot it, so long-running targets no longer retain the extra ~31k slots.
Fixed in `push_bounded`: once capacity reaches half of `limit`, we now `reserve_exact` up to `limit` instead of letting the next geometric doubling overshoot it, so long-running targets no longer retain the extra ~31k slots.
_🤖 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:
61ed029988ℹ️ 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".
@@ -552,3 +552,3 @@negotiated: None,graph_history: VecDeque::with_capacity(HISTORY_LIMIT),graph_history: VecDeque::new(),last_sample: None,For a target receiving at least 65,537 replies,
VecDeque's geometric growth increases this buffer's capacity from 65,536 to 131,072;push_boundedlater limits its length to 100,000 but never releases the 31,072 excess slots. Long-running active targets therefore retain more graph-history heap than the previous exact-limit allocation, with the overhead multiplied in multi-target runs, so grow the queue in capped increments or reserve only the final remainder as it approachesHISTORY_LIMIT.AGENTS.md reference: AGENTS.md:L53-L58
Useful? React with 👍 / 👎.
A future implementation could reserve a small initial buffer while still avoiding the problematic
HISTORY_LIMITpreallocation, but this exact-capacity assertion would reject it despite preserving the intended memory invariant. Assert the meaningful upper bound, or remove/consolidate this test, rather than pinningVecDeque's private allocation mechanism.AGENTS.md reference: AGENTS.md:L104-L106
Useful? React with 👍 / 👎.
Removed the test — swapped for a plain upper-bound assertion (
capacity() < HISTORY_LIMIT + HISTORY_LIMIT / 10) added toecho_reply_appends_bounded_primary_historyinstead of pinningVecDeque's private allocation mechanism.🤖 Addressed by Claude Code
@@ -552,3 +552,3 @@negotiated: None,graph_history: VecDeque::with_capacity(HISTORY_LIMIT),graph_history: VecDeque::new(),last_sample: None,Fixed in
push_bounded: once capacity reaches half oflimit, we nowreserve_exactup tolimitinstead of letting the next geometric doubling overshoot it, so long-running targets no longer retain the extra ~31k slots.🤖 Addressed by Claude Code