Development record
the probe adapters' truncation message says the rest of the tree was not walked, but the per-directory read bound added for iss-112 can set truncated while the walk completed everything else; the over-warning is in the conservative direction, not a loud-staging violation, but the message is imprecise about WHAT was truncated
issueresolvednitpickiss-133
the probe adapters' truncation message says the rest of the tree was not walked, but the per-directory read bound added for iss-112 can set truncated while the walk completed everything else; the over-warning is in the conservative direction, not a loud-staging violation, but the message is imprecise about WHAT was truncated
Grounds
- pursued: a coverage note says which bound cut the scan and what it cut, and claims the rest of the tree went unwalked only when the walk actually stopped; shown wrong if a depth or per-directory truncation renders as the walk cap, which the tests assert
Frontmatter
| id | iss-133 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | nitpick |
.abcd/work/issues/resolved/iss-133-truncation-message-overstates-scope.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26082600000000042026-08-26 — Bug-hunt round 8 (bughunt-a, state #368): baseline green; five
- iss-112WalkFiles caps the number of regular files it returns, but fs.WalkDir calls ReadDir(-1) on every directory it enters, so a single directory holding millions of entries balloons memory before the file cap can apply. The maxWalkFiles doc comment claims the walk stays bounded in memory, which is only true of the returned slice. ListDir already bounds this with ReadDir(maxDirEntries); the walk does not share that guard. Found by an independent security review of the itd-95 diff.