Development record
readDirBounded's doc comment claims sorted-by-name determinism, which holds only at or under the bound; a directory exceeding the bound yields a readdir-order subset that is then sorted, so WHICH entries survive is nondeterministic (loud via truncated, consistent with ListDir, pathological trigger only)
issueresolvednitpickiss-134
readDirBounded's doc comment claims sorted-by-name determinism, which holds only at or under the bound; a directory exceeding the bound yields a readdir-order subset that is then sorted, so WHICH entries survive is nondeterministic (loud via truncated, consistent with ListDir, pathological trigger only)
Grounds
- pursued: the doc states only what the function guarantees; shown wrong if readDirBounded returns other than bound sorted distinct entries with more=true above the bound, or the whole sorted directory at or under it, which the contract test asserts
Frontmatter
| id | iss-134 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | nitpick |
.abcd/work/issues/resolved/iss-134-readdirbounded-determinism-doc-claim.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2608270908348796probe's record-home listing reads at most maxDirEntries entries per directory, so a home beyond the bound silently drops records from every graveyard scanner's input set with no per-scan notice — the input-set sibling of the resolved per-signal cap announcements, beside the iss-134 determinism note