Repository navigation
id(cli): test_cli_parse_cat stack-overflows in the pkgs/id test binary (pre-existing, parse path) #3438
Closed as not planned
Description
Problem
In the pkgs/id test binary, cli::tests::test_cli_parse_cat aborts with a stack overflow, even run in isolation:
$ id-<hash> cli::tests::test_cli_parse_cat --exact --test-threads=1
thread 'cli::tests::test_cli_parse_cat' has overflowed its stack
fatal runtime error: stack overflow, aborting
Found 2026-11-01 by queue task 5262 (lane F) while running the full pkgs/id suite on the laptop from PR 3420's head (74c1a6e). The PR's diff touches only pkgs/id/src/commands/serve.rs (is_process_alive + its test), which the CLI parse path does not call — so this failure is pre-existing relative to that change, not caused by it. All commands::serve tests pass (15/15).
Acceptance
- Reproduce on clean
mainand confirm the overflow is in the parse path (likely clap derive recursion / large nested subcommand graph exceeding the test-thread stack). - Fix so
test_cli_parse_catpasses in the normal test-thread configuration (e.g. parse on a spawned thread with a larger stack in the test, or reduce parse recursion), or document the requiredRUST_MIN_STACKif that is the intended configuration. - Full
pkgs/idtest binary run completes without aborting.
Acceptance criteria
-
test_cli_parse_catruns to completion in the pkgs/id test binary without a stack overflow (pass, or a normal assertion failure if the underlying parse behavior is separately wrong). - The root cause is identified in the PR: either the recursive parse path gains a depth bound / iterative shape, or the test's input is shown to be invalid and corrected — not merely a larger test-thread stack.
- The rest of the pkgs/id test suite stays green in CI.
Metadata
Metadata
Assignees
Labels
Package/app: id (pkgs/ or apps/ in this repo)Small: expected under 2 hours of workSomething isn't working (prefixed form of the classic bug label)Intake review done: acceptance criteria, links, and normalized labels addedOrdinary priority (the default)Filed or worked by the queue/worker pilotQueue packet kind: verify, reproduce, and route this item
Activity
developing-today commentedon Nov 1, 2026
CODE-1312
dezren39 commentedon Nov 1, 2026
Refinement from the filing lane (queue task 5262 follow-up, noted during task 5356):
pkgs/id/.cargo/config.tomlsetsRUST_MIN_STACK = "8388608"under[env]. The stack overflow in the original report was observed running the compiled test binary directly, which bypasses that config; undercargo testthe env applies and the test may pass. Whoever picks this up: first reproduce viacargo test --lib cli::tests::test_cli_parse_cat(with the config env in force) before treating it as a code defect — the fix may be documentation (the binary is only supported via cargo test) rather than a parser change. The serve-module results in the original filing are unaffected (they passed in the same direct run at far shallower stack depth).dezren39 commentedon Nov 1, 2026
Intake review
Related: filed by lane F during its 2026-11-01 shift and noted there as pre-existing on main. No merged PR references this issue as of this run. Sibling context: the pkgs/id monolith split is #3447.
Notes: a stack overflow in a parse path is worth treating as a potential product bug (unbounded recursion on adversarial input), not just a test bug — the intake expectation is that the worker determines which one it is before fixing. Risk: medium until that determination is made; effort/s assumes the parse-path guard shape.
Suggested approach: reproduce under the test binary, bisect the input that drives the recursion, then bound the recursion or convert it to an explicit stack.
🤖 Agent note · done
dezren39 commentedon Nov 1, 2026
Second test in this family, found 2026-11-01 during queue task 2952 work on #168:
cli::tests::source_only_mode_is_opt_in_and_requires_world_modealso stack-overflows the pkgs/id test binary (fatal runtime error: stack overflow, SIGABRT), reproduced in isolation on clean mainbda855c66with all local changes stashed — pre-existing, not a regression of the #168 change. It aborts the full--libsuite at that point, so suite runs stop there until this is fixed.dezren39 commentedon Nov 1, 2026
Data point from queue task 4859 (2026-11-01): the sibling test
cli::tests::test_cli_parse_world_caps_ceilingalso aborts the pkgs/id test binary withfatal runtime error: stack overflow(SIGABRT) when run alone with--exacton clean main b4c4a99 (laptop). This is why a bareworld_capstest filter aborts: it substring-matches this cli test. Theworld_caps::module tests themselves pass 16/16. Same parse-path family as test_cli_parse_cat.developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: picked_up
task: 8258 (repo-health-code-pilot, repo-worker-code — OpenChamber scheduled lane)
state: claimed; fresh issue state OPEN; no held, user/owned, do-not-merge, or do-not-auto-edit labels
at: 2026-11-03T21:08Z
next: refresh main in task worktree, reproduce with cargo config active, and check for an existing fix PR before routing.
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: triaged → closed (not planned)
queue: repo-health-code-pilot
task: 8258 (repo-worker-code — OpenChamber scheduled lane)
at: 2026-11-03T21:24Z
Triage finding (current main f34b6fd)
The report is reproducible only when the compiled test harness is run directly without
RUST_MIN_STACK:env -u RUST_MIN_STACK target/debug/deps/id-cf7e07685103fdc8 cli::tests::test_cli_parse_cat --exact --test-threads=1aborts with stack overflow. The supported Cargo invocation frompkgs/id,cargo test --lib cli::tests::test_cli_parse_cat -- --exact --test-threads=1, passes (1 passed, 0 failed); running the same test binary withRUST_MIN_STACK=8388608also passes (1/1). Currentpkgs/id/.cargo/config.tomlsets that value, and existing project docs (docs/2026-10-18T00-00-00Z_reference_platform_state/...) explain that the id tests require it and must be run frompkgs/id. The direct executable invocation bypasses Cargo config; no source/parser defect was reproduced in the supported test path. No relevant PR is linked to this issue.Disposition: not planned as a code fix; use the documented Cargo test command. If direct test-binary execution becomes a supported requirement, reopen with that requirement and address the test-thread stack usage explicitly.
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: post-disposition current-main refresh
task: 8258 (completed)
at: 2026-11-03T21:27Z
After the triage comment, the primary clone refreshed to main
dcca6cd510866556a00dedb2c92b7d21cf817e2b. The eight commits since tested basef34b6fd4edo not changepkgs/id/src/cli.rs,pkgs/id/.cargo/config.toml, or the cited test-stack documentation; the relevant finding and disposition are unchanged.