Skip to content

refactor(cache): restructure cache lookup and update around the task's fs story - #601

Open
wan9chi wants to merge 1 commit into
claude/fs-fingerprint-recordsfrom
claude/task-fs-seam
Open

refactor(cache): restructure cache lookup and update around the task's fs story#601
wan9chi wants to merge 1 commit into
claude/fs-fingerprint-recordsfrom
claude/task-fs-seam

Conversation

@wan9chi

@wan9chi wan9chi commented Aug 9, 2026

Copy link
Copy Markdown
Member

Motivation

The filesystem side of a task run — snapshotting inputs, judging traced accesses, the read-write-overlap verdict — is spread across the lookup, update, and observation code, so the unsettled overlap policy can only be exercised by running a whole task through the engine.

This gives it one seam (stack: 2/3, on top of #600):

  • TaskFs::pre_run — before the task executes: validate the io configuration, snapshot the listed inputs, and report the first input changed since a previous run's fingerprints.
  • TaskFs::post_run — after it finished: judge the traced accesses and conclude InputModified (caching unsound) or Cacheable with the run's fingerprints and outputs.

The seam makes the overlap policy and its filters drivable with synthetic traces on temp directories — the new unit tests in task_fs/task_run.rs do exactly that, covering the verdict across all auto-tracking combinations, per-side gating, negative-glob/ignore filtering, access normalization, and fingerprint round-trips.

Lookup flips to fetch-first so pre_run can compare against the stored fingerprints; since that makes the entry fetch and the old-key miss classification adjacent, both now run in one deferred read transaction under a single lock hold (fetch_entry), closing the window where a concurrent run of the same task could break the classifier's the-key-just-missed assumption. The cache module shrinks to storage primitives; FspyTracking dissolves into TaskFs.

The task_fs module tree deliberately mirrors a standalone-crate layout: #594 moves it out of the engine wholesale.

🤖 Generated with Claude Code

…s fs story

Give the filesystem side of a task run one seam: TaskFs::pre_run (before the
task executes: validate io config, snapshot the listed inputs, and report the
first input changed since a previous run's fingerprints) and TaskFs::post_run
(after: judge the traced accesses and conclude InputModified or Cacheable with
the run's fingerprints and outputs). The seam makes the read-write-overlap
policy and its filters drivable with synthetic traces on temp directories —
the new unit tests in task_fs/task_run.rs do exactly that.

Lookup flips to fetch-first so pre_run can compare against the stored
fingerprints, and — since that makes the entry fetch and the old-key miss
classification adjacent — both now run in one deferred read transaction under
a single lock hold (fetch_entry), closing the window where a concurrent run
could break the classifier's the-key-just-missed assumption. The cache module
shrinks to storage primitives; FspyTracking dissolves into TaskFs.

The task_fs module tree mirrors a standalone-crate layout on purpose: the
follow-up moves it out of the engine wholesale.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 9, 2026

Copy link
Copy Markdown

fspy benchmark

linux

dynamic/launch             change  +0.67%  [ -3.36% ..  +5.33%]  overhead   +57.17%
dynamic/access             change  -0.01%  [ -5.46% ..  +3.04%]  overhead    +5.67%
static/launch              change  +0.80%  [ -5.30% ..  +6.91%]  overhead  +178.34%
static/access              change  -0.20%  [ -2.44% ..  +1.00%]  overhead  +754.02%

macos

dynamic/launch             change  +0.34%  [ -1.77% ..  +2.63%]  overhead  +212.90%
dynamic/access             change  +0.00%  [ -2.44% ..  +1.96%]  overhead    +3.05%

windows

dynamic/launch             change  +0.79%  [ -2.35% ..  +5.09%]  overhead   +27.38%
dynamic/access             change  +0.35%  [ -1.28% ..  +1.97%]  overhead    +1.98%

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