Skip to content

TIMING BASELINE: heavy fan-out PR on unmodified post-#2864 main - #18

Closed
b7r6 wants to merge 10 commits into
mainfrom
ci/timing-baseline
Closed

b7r6 wants to merge 10 commits into
mainfrom
ci/timing-baseline

Conversation

@b7r6

@b7r6 b7r6 commented Oct 2, 2026 •

Copy link
Copy Markdown
Owner

What and why

Fork-only CI timing probe (do not merge). A heavy, big-dependency-cone change (edit to the foundational nativelink-util crate, which invalidates a large downstream compile cone) used to measure the cold whole-PR critical path and per-lane breakdown.

How was this verified?

This PR exists to be measured by CI itself; the job durations are the artifact. Compared against its sibling timing PR under identical cache conditions.

Risk

None. Fork-only measurement branch, never merged. The source change is a two-line comment in nativelink-util/src/lib.rs.

AI assistance

An agent (Claude Opus 4.8) created the probe and ran the measurement under human direction.

rohnnyjoy and others added 10 commits September 30, 2026 21:27
…hina#2826)

should_timeout_operation ended an Executing action once Action.timeout
had passed since it was assigned. The worker enforces the same timeout,
but its clock starts when the command starts, after input fetch, so the
scheduler always fired first. The action was requeued onto the worker
still running it, which refused with AlreadyExists; the retries ran out,
and when the worker's own DEADLINE_EXCEEDED result arrived it was
treated as a stray and the worker was disconnected, taking every other
action on it down too.

The scheduler now enforces Action.timeout in every liveness case, at
Action.timeout plus no_event_action_timeout, measured from the later of
the assignment and the worker's last update on the action. A live
worker reports first, so no liveness special-casing is needed, and the
scheduler still ends an action whose worker never reports: a hung input
fetch, an unkillable child, a broken timeout_handled_externally wrapper,
or an orphan no instance reaps.

The client's DEADLINE_EXCEEDED message now names the deadline that
fired, instead of always citing no_event_action_timeout.

This is the interim: the scheduler cannot observe when the command
starts. TraceMachina#2827 tracks the worker reporting command start as an operation
transition, so the deadline can be anchored to that event.

Co-authored-by: Johnny <[email protected]>
…store, and a missing input names its digest so the client re-uploads it (TraceMachina#2855)
…the worker evicted and idle (TraceMachina#2856)

* Worker: no scheduler call awaited in the run loop, a deadline on keepalives and acknowledgements that reconnects, and HTTP/2 keepalive on the scheduler channel

* Worker: the GoingAway calls on shutdown carry the same deadline

* Worker: the layout CI's rustfmt asks for

* Keep the scheduler stream flowing: ordered processing off the reader, no deadlines on stream messages

* Qualify Code in the worker API server test

* Box the action future before the launch closure

* Box the action chain inside the action closure

* Raise the binary's recursion limit for the worker's action future

* Use try_update for the filesystem store generation counter
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* chore(deps): update rust crate serial_test to v4
* Update MODULE.bazel.lock
@github-actions

This comment has been minimized.

@b7r6

b7r6 commented Oct 3, 2026

Copy link
Copy Markdown
Owner Author

Closing fork-only measurement/experiment PR; superseded by the single clean PR on ci/bazel-dev-warming (#25).

@b7r6 b7r6 closed this Oct 3, 2026
@b7r6
b7r6 deleted the ci/timing-baseline branch October 15, 2026 11:54
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.

4 participants