Local audio transcript cache misses because fileMtime is omitted on write

[alfozan]

Summary

Repeated --extract runs on the same unchanged local audio file re-transcribe instead of serving the cached transcript.

Repro

summarize --plain /path/to/audio.opus --extract
summarize --plain /path/to/audio.opus --extract

Observed

The second run still logs transcription done media file: yt-dlp and calls the transcription provider. If the second run uses an invalid transcription API key, it fails with the provider error instead of serving the cached transcript.

Expected

The second run should hit the transcript cache for the same unchanged local file.

Likely Cause

For local files, summarizeMediaFile() passes fileMtime into transcript resolution. transcriptCache.get() builds its key with fileMtime, but transcriptCache.set() writes using a key that omits fileMtime. Since buildTranscriptCacheKeyValue() includes fileMtime, local-file reads and writes do not match.

Suggested Fix

Include fileMtime when building the write key in transcriptCache.set(), and add a regression test against the real cache store implementation.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 8, 2026, 1:00 AM ET / 05:00 UTC.

Summary
Keep open: current main still has a source-level mismatch where local transcript cache reads include fileMtime but the CLI SQLite cache write key omits it, so unchanged local audio can miss the cache.

Reproducibility: yes. The provided two-run --extract path has a high-confidence source reproduction because local media passes fileMtime, reads key by it, and the real SQLite write path ignores it; I did not execute a live transcription provider during this read-only review.

Next step
This is a narrow source-proven cache-store mismatch with clear implementation files and a direct regression-test path.

Review details

Best possible solution:

Update the CLI SQLite transcript cache write key to include fileMtime, then add a real createCacheStore regression test that writes and reads the same local-file URL with matching and changed mtimes.

Do we have a high-confidence way to reproduce the issue?

Yes. The provided two-run --extract path has a high-confidence source reproduction because local media passes fileMtime, reads key by it, and the real SQLite write path ignores it; I did not execute a live transcription provider during this read-only review.

Is this the best way to solve the issue?

Yes. Including fileMtime in the CLI store write key and covering the real store is the narrowest maintainable fix because the core interface and read path already carry the value.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The fix should preserve existing URL transcript cache compatibility by treating missing or null fileMtime the same way current read keys do.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 769d01f0898f.

Label changes

Label changes:

• add P2: This is a normal-priority cache correctness bug scoped to local media extraction and repeated transcription calls.
• add impact:other: The issue affects transcript cache correctness, provider usage, and local extraction reliability outside the more specific owned impact labels.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority cache correctness bug scoped to local media extraction and repeated transcription calls.
• impact:other: The issue affects transcript cache correctness, provider usage, and local extraction reliability outside the more specific owned impact labels.

Evidence reviewed

Acceptance criteria:

• pnpm -s vitest run tests/cache.store.test.ts tests/transcript.cache.filemtime.test.ts tests/cli.asset.audio-file-transcript-cache.test.ts
• pnpm -s check

What I checked:

• Local media forwards fileMtime: summarizeMediaFile computes a local file mtime and passes it into transcript resolution options for media extraction. (src/run/flows/asset/media.ts:233, 769d01f0898f)
• Transcript reads use fileMtime: The CLI transcript cache read path builds the SQLite lookup key with the supplied fileMtime. (src/cache.ts:367, 769d01f0898f)
• Transcript writes omit fileMtime: The CLI transcript cache write path destructures no fileMtime and calls getTranscriptKey(url), whose helper only includes URL and namespace, so writes land under a different key from local-file reads. (src/cache.ts:398, 769d01f0898f)
• Core write passes fileMtime to cache implementations: writeTranscriptCache already forwards fileMtime to transcriptCache.set, which narrows the remaining bug to the CLI store implementation. (packages/core/src/content/transcript/cache.ts:163, 769d01f0898f)
• Docs define fileMtime as part of transcript keys: The cache design docs say transcript cache keys include {url, namespace, fileMtime?, formatVersion} for local-file invalidation. (docs/cache.md:40, 769d01f0898f)
• History shows an incomplete write-path fix: Commit 945c0ea added fileMtime to the cache interface and core write helper, but it did not touch src/cache.ts, leaving the real SQLite store write key unchanged. (packages/core/src/content/transcript/cache.ts:163, 945c0ea365d5)

Likely related people:

• @mvance: Introduced local audio transcript caching and later added fileMtime threading through the core transcript write path, which is adjacent to the remaining CLI store mismatch. (role: introduced behavior; confidence: high; commits: f177cf61d349, 945c0ea365d5; files: src/run/flows/asset/media.ts, src/cache.ts, packages/core/src/content/transcript/cache.ts)
• @steipete: The current released snapshot/blame for the CLI cache store lines is the v0.16.3 release commit, so this is a useful routing signal for release-aware cache fixes. (role: release integrator; confidence: medium; commits: fcf8c8e5e98d; files: src/cache.ts, src/cache-keys.ts, packages/core/src/content/transcript/cache.ts)
• Anton Novoselov: Recent history shows work on media URL routing through summarizeMediaFile, adjacent to the local/remote media transcript cache flow. (role: adjacent area contributor; confidence: low; commits: 138b1e59f5e3; files: src/run/flows/asset/media.ts, src/run/flows/asset/input.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Fixed on main by PR #241, merge commit 4beaa93735812d788debd87dd1d5cc7ce170fe05.

Proof:

• Current main repro before the fix used a real createCacheStore: write transcript with fileMtime: 1234, read the same URL with fileMtime: 1234, result MISS.
• Fixed branch returned cached transcript for the same store script.
• Focused tests passed: pnpm test tests/cache.store.test.ts tests/transcript.cache.filemtime.test.ts tests/cli.asset.audio-file-transcript-cache.test.ts.
• Full gate passed: pnpm -s check.
• Autoreview passed clean: local mode and branch mode against origin/main.
• GitGuardian Security Checks, extension-e2e, and test (24) passed.

Thanks @alfozan.