Skip to content

test(filesystem_store): widen open-file drain budget to de-flake asan - #48

Closed
b7r6 wants to merge 1 commit into
mainfrom
fix/evicting-map-batch-eviction
Closed

b7r6 wants to merge 1 commit into
mainfrom
fix/evicting-map-batch-eviction

Conversation

@b7r6

@b7r6 b7r6 commented Oct 7, 2026 •

Copy link
Copy Markdown
Owner

What and why

Lane A stability fix from the findings catalog (see nativelink-findings-2026-10-05.csv
on the meta/findings-catalog-2026-10-05 branch), rebased onto OSS main
@bf4b3aa855. This fork PR exists to validate the change on CI that is
representative of upstream PR lanes (public read-only cache, same endpoints)
before any upstream submission.

How was this verified?

The branch carries its own regression tests (fails-without where the fix
class allows it — see the branch's test commits). This PR's purpose is the
full representative CI run; green here rehearses the exact checks an
upstream PR would face.

Risk

Fork-internal validation PR; nothing lands anywhere by merging this. The
underlying fix's risk assessment happens at upstream-submission time.

AI assistance

Agent-assisted pipeline (Claude) for rebase and PR mechanics under my
direction; the fix itself carries verification in its tests.

@b7r6
b7r6 force-pushed the fix/evicting-map-batch-eviction branch 3 times, most recently from 74d7370 to 671ccd4 Compare October 8, 2026 16:32
@b7r6
b7r6 force-pushed the fix/evicting-map-batch-eviction branch 2 times, most recently from ce0ba79 to d095cb8 Compare October 15, 2026 11:19
…ried blob

`sizes_for_keys` snapshotted `lru.len()` once for the whole batch and
reused that stale length in `should_evict` for every key in the loop.

When the map sits one entry over `max_count` — e.g. an action-input
lease (or a TTL-pending entry) pins it at `max_count + 1` — the first
unleased queried key is popped, bringing the real length back to
`max_count`. But iterations 2..N still saw the stale `lru_len ==
max_count + 1`, so `is_over_count` stayed true and every remaining
queried, unleased entry was popped too: remove-callbacks queued,
`FileEntryImpl` unref deleting the backing files.

The batch then reports `None` for all N digests, the client treats them
as absent and re-uploads, and a plain existence check (`has()` →
FilesystemStore → `sizes_for_keys`) has destroyed every resident blob it
was only asked about.

Fix: keep a mutable working count and decrement it as entries are
reaped, so the over-count predicate is re-evaluated against the current
length each iteration. Eviction now stops the moment the map is back
at/under the limit — a size/existence query evicts at most the genuine
overage and never cascades.

Adds a white-box regression test that pins the map one over `max_count`
with a leased entry (bypassing the insert-time eviction pass the way a
held lease does) and asserts a batch `sizes_for_keys` over the resident
keys leaves all but the single-entry overage present. It fails on the
stale-len code (all N reported missing) and passes with the fix.

Provenance: adversarial review fleet, highest-severity finding.

Co-Authored-By: Claude Fable 5 <[email protected]>
@b7r6
b7r6 force-pushed the fix/evicting-map-batch-eviction branch 2 times, most recently from d689654 to f9cc857 Compare October 15, 2026 11:34
@b7r6

b7r6 commented Oct 15, 2026

Copy link
Copy Markdown
Owner Author

Landed upstream as TraceMachina#2840. Closing.

@b7r6 b7r6 closed this Oct 15, 2026
@b7r6
b7r6 deleted the fix/evicting-map-batch-eviction branch October 15, 2026 19:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant