This is the record of an abcd-managed repository

abcdBetav0.16.2 · 2026-11-06

Development record

hook salvage entries invoke bootstrap.sh with no timeout budget below its 180s curl worst case so a slow-link provision is killed and suppressed for ten minutes

issueresolvedminoriss-323

hook salvage entries invoke bootstrap.sh with no timeout budget below its 180s curl worst case so a slow-link provision is killed and suppressed for ten minutes

Evidence

hooks/hooks.json — SessionStart (:18) declares "timeout":240; the four salvage entries (UserPromptSubmit :3, PreToolUse :24, PreCompact :35, SessionEnd :45) invoke the same bootstrap.sh with NO timeout, inheriting the harness 60s default (dcn-2608010000000007 records the 60s default and the 180s worst case as the reason SessionStart got 240). On a slow link the salvage hook is killed at 60s after .bootstrap.attempt is stamped, suppressing retry for 10 min, output to /dev/null.

Adversarial verdict: CONFIRMED (minor) — RECORD-ONLY

Default-timeout premise verified (60s, dcn-2608010000000007 + the hooks reference). State is kill-safe (trap cleanup; verified-then-mv install; no corrupt binary). Not fixed this round because the correct value is a design judgment: setting 240 on UserPromptSubmit would quadruple the user's synchronous prompt stall to 4 minutes. Recommended direction (for a human): a modest explicit timeout (90-120s) on the salvage entries, and — separately valuable — a test asserting the per-event timeout values (none exists today; even SessionStart's 240 is unpinned). No test currently pins any timeout field.

Grounds

  • pursued: a slow-link salvage gets 120s with a visible spinner message instead of the host default and a silent stall; hooks_timeout_test fails if any event's timeout or a salvage statusMessage changes, and it would be shown wrong by a host that ignores statusMessage on plugin hooks

Frontmatter

idiss-323
typeissue
lifecycleresolved
severityminor

mentions11