Give a promoted view back the time it saw a file #5

Closed

qwolff wants to merge 5 commits from fix/promoted-view-mtime into main

pull from: fix/promoted-view-mtime

merge into: tilo:main

tilo:main

tilo:dev/schema-step-order

tilo:t-join-release

tilo:t-work-booking

tilo:t-ahead-deadlock-wip

tilo:t-hotfix-9ae

tilo:t-width-work

tilo:t-id-token-renew

tilo:t-claim-unkept

tilo:t-resume-live

tilo:t-run-record

tilo:t-all-lockfiles

tilo:t-relay-offset

tilo:t-blame-event

tilo:t-freer-links

tilo:t-load-tests

tilo:t-jobserver2

tilo:t-starved-timeout

tilo:t-client-pack

tilo:t-offline-config

tilo:t-test-plan

tilo:t-told-resume2

tilo:t-jobserver

tilo:t-told-resume

tilo:t-outbound2

tilo:t-crash-open-bench

tilo:t-told-once

tilo:guest-never-below-given

tilo:admit-page-cache-active

tilo:pooled-admission

tilo:driver-give-back

tilo:no-sizes

tilo:one-driver-per-check

Conversation 0 Commits 5 Files changed 1 +74

qwolff commented 2026-10-19 03:13:14 +00:00

Owner

Copy link

Root cause

After a job touches a file whose content differs from its build snapshot, it may promote its upper as a new build layer without ever compiling that file. promote records the view the job saw: the touched file is recorded at the touch time, while the layers below can still hold an artifact compiled from the older content.

A later job at the same content saw only the source snapshot's single SOURCE_MTIME_NS time. The guard in Snapshots::touched restored a same-content file's view time only when the source time was newer than build.sealed_ns. Source snapshots are older than every build, so that was never true: the file kept the 2000-01-01 time, cargo compared it with the stale artifact's own old dep-info time, called it fresh, and kept the artifact.

Fix

Restore a same-content file's view time whenever the view saw it later than the source snapshot (seen > mine). The normal case still copies nothing: untouched files have seen == mine == SOURCE_MTIME_NS. Dropping the old sealed-time condition is safe because subsequent promotion records a touched time later than every compile in the layers below.

The regression test promotes a view after touching a file without a compile and then checks that the next job restores that view time. Separate cases cover unchanged files (no touched layer) and different content (made newer than the build).

Verification

• snapshots::tests:: on aarch64: 21 passed, 0 failed (cargo test -p t --bin t snapshots::tests::, run rf0de443706).
• The new regression test fails on the old guard with [] instead of ["dep.rs"] (cargo test -p t --bin t snapshots::tests::a_promoted_view_restores_the_time_of_a_file_its_job_did_not_compile -- --exact, run r2bb3f81ef6).
• cargo clippy -p t --all-targets -- -D warnings passes.

Operational notes

Deploy the new server and worker image to every node. Existing cached check results are keyed by source inputs, so they are not invalidated by this code change; after deployment, re-run the affected checks with --force on the fixed version to replace results produced by the stale build. Existing build snapshots need no manual deletion: the guard restores the recorded view time on use and cargo rebuilds the stale artifact. Views written by an older scheme may cause a one-time extra touch/rebuild until they are replaced or evicted normally.

## Root cause After a job touches a file whose content differs from its build snapshot, it may promote its upper as a new build layer without ever compiling that file. `promote` records the view the job saw: the touched file is recorded at the touch time, while the layers below can still hold an artifact compiled from the older content. A later job at the same content saw only the source snapshot's single `SOURCE_MTIME_NS` time. The guard in `Snapshots::touched` restored a same-content file's view time only when the source time was newer than `build.sealed_ns`. Source snapshots are older than every build, so that was never true: the file kept the 2000-01-01 time, cargo compared it with the stale artifact's own old dep-info time, called it fresh, and kept the artifact. ## Fix Restore a same-content file's view time whenever the view saw it later than the source snapshot (`seen > mine`). The normal case still copies nothing: untouched files have `seen == mine == SOURCE_MTIME_NS`. Dropping the old sealed-time condition is safe because subsequent promotion records a touched time later than every compile in the layers below. The regression test promotes a view after touching a file without a compile and then checks that the next job restores that view time. Separate cases cover unchanged files (no touched layer) and different content (made newer than the build). ## Verification - `snapshots::tests::` on aarch64: 21 passed, 0 failed (`cargo test -p t --bin t snapshots::tests::`, run `rf0de443706`). - The new regression test fails on the old guard with `[]` instead of `["dep.rs"]` (`cargo test -p t --bin t snapshots::tests::a_promoted_view_restores_the_time_of_a_file_its_job_did_not_compile -- --exact`, run `r2bb3f81ef6`). - `cargo clippy -p t --all-targets -- -D warnings` passes. ## Operational notes Deploy the new server and worker image to every node. Existing cached check results are keyed by source inputs, so they are not invalidated by this code change; after deployment, re-run the affected checks with `--force` on the fixed version to replace results produced by the stale build. Existing build snapshots need no manual deletion: the guard restores the recorded view time on use and cargo rebuilds the stale artifact. Views written by an older scheme may cause a one-time extra touch/rebuild until they are replaced or evicted normally.

qwolff added 1 commit 2026-10-19 03:13:14 +00:00

Give a promoted view back the time it saw a file ... 6a37a83915

A job touches files whose contents differ from its build snapshot, and promotes its upper as a new layer even when it never compiled one of those files. Its view then records the file at the touch time, while the layers below can still hold an artifact compiled from the older content. A later job at the same content saw only the source snapshot's one time, and the old guard skipped restoring the view's time because that source time is older than the build. Cargo then compared the source with the stale artifact's own old time and kept it.\n\nRestore a same-content file's view time whenever the view saw it later than the source snapshot. Unchanged files still share the source snapshot's one time, so the normal case copies nothing.

qwolff added 4 commits 2026-10-19 07:05:41 +00:00

Merge main into fix/promoted-view-mtime ... fc656bdaea

Main's snapshot rework now records what each build's job saw and restores those times for unchanged content, which covers the promoted-view case this branch fixed. Keep the regression tests adapted to the new snapshot model so that behavior stays pinned.

Merge main into fix/promoted-view-mtime ... b486517f28

Main's snapshot rework now records what each build's job saw and restores those times for unchanged content, which covers the promoted-view case this branch fixed. Keep the regression tests adapted to the new snapshot model so that behavior stays pinned.

Merge remote-tracking branch 'origin/main' into reconcile-pr5 7cf34753a3

Pin the promoted view's restored mtime to what the build recorded ... d6bed74dad

Assert that the restored time is newer than the build below, not merely newer than the fixed source timestamp, and that an unchanged file stays out of the touched set while the changed one keeps the promoted view's time.

qwolff closed this pull request 2026-10-28 03:48:50 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

tilo/t!5

No description provided.