Skip to content

Scheduler: kill_revoked_operations identifies a dispatch by generation, not timestamp - #43

Open
b7r6 wants to merge 1 commit into
mainfrom
fix/kill-revoked-revalidates
Open

b7r6 wants to merge 1 commit into
mainfrom
fix/kill-revoked-revalidates

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/kill-revoked-revalidates branch 2 times, most recently from 33adde4 to 7f89f6f Compare October 7, 2026 20:31
…n, not timestamp

kill_revoked_operations snapshots (worker, operation) pairs under the
scheduler mutex, then confirms revocation against the state manager
lock-free. If the operation is declined/requeued and re-dispatched to
the same worker inside that window, the final locked re-guard used to
pass on the fresh entry and the kill landed on the new, legitimate
dispatch.

An earlier version of this fix carried the entry's dispatched_at
timestamp as the dispatch's identity, but a timestamp is not an
identity: dispatched_at has second resolution
(duration_since(UNIX_EPOCH).as_secs()), so a requeue-and-redispatch
inside one wall-clock second carries the same dispatched_at and the
stale kill still lands. Review caught the collision; the regression
test now pins both dispatches to the same second and fails on the
timestamp scheme.

Each dispatch now carries a dispatch_generation: a scheduler-wide u64
incremented under the scheduler mutex at send time, stored on the
running_action_infos entry. The sweep snapshots the generation and
worker_notify_kill_operation only sends the kill if the entry under
the lock still carries it; a re-dispatch always gets a strictly
greater generation, so a stale kill can never match. The counter is
scheduler-wide rather than per-worker: a per-worker counter would
restart when a worker re-registers under the same id, letting a stale
snapshot from the old incarnation match a fresh dispatch on the new
one. dispatched_at stays as a timestamp for the acknowledgement
timeout math.

Also registers tests/kill_revoked_redispatch_race_test.rs in the
Bazel rust_test_suite, which had not picked it up.

Provenance: adversarial review fleet; incompleteness found by a
follow-up review of TraceMachina#2838.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@b7r6
b7r6 force-pushed the fix/kill-revoked-revalidates branch from 7f89f6f to 2760207 Compare October 8, 2026 17:51
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