perf: skip storage footprint republish when scan is unchanged

[soohanpark]

What

UsageStore.applyStorageFootprints reassigned the observable providerStorageFootprints on every scan, even when the scanned bytes were identical. Storage scans run on every menu open (refreshStorageFootprintsForOverview) and roughly every 5 minutes, so each no-op scan woke the menuObservationToken observation → invalidateMenus, which clears the merged-menu content caches (clearMergedSwitcherContentCaches) and schedules avoidable rebuild work — pure churn when nothing the user sees changed.

The reason a guard wasn't already effective: ProviderStorageFootprint is Equatable, but it carries updatedAt: Date, stamped fresh on each scan, so two scans of identical on-disk data never compare equal.

Change

• Add ProviderStorageFootprint.hasSameContents(as:) — value equality over everything except updatedAt (which is never surfaced to the UI).
• In applyStorageFootprints, reuse the existing footprint when only the timestamp would change, then guard the observable write with !=. An unchanged scan is now a true no-op and fires no observation.

Test

Adds repeated identical storage refresh does not republish observable footprints — asserts (via withObservationTracking) that a second scan over identical on-disk data does not republish providerStorageFootprints. Fails before the change, passes after.

Full swift test: green (the only failure on my machine is the pre-existing locale-dependent MiniMax date assertion at MenuCardModelTests.swift:735, unrelated to this change — it hardcodes an en_US date string).

Manual verification (release build)

Built and ran a release build (Scripts/compile_and_run.sh) and exercised the merged Overview menu — repeated open/close, Claude↔Codex tab switching, and chart-row hovers — while streaming the app's own os_log (subsystem == "com.steipete.codexbar"). Both logMenuOperationDurationIfSlow (≥150 ms) and logChartRenderDurationIfSlow (≥50 ms) log via the same .warning path, which persists to the log store, so a slow op would have been captured.

Over the session:

• slow menu operation warnings (open/close/tab-switch blocking the main thread ≥150 ms): 0
• crashes / hangs: 0
• slow chart render: 1 — 55.1 ms on the first hydrate of usageHistoryChart (first hover only; subsequent hovers are skipped by the existing render-signature guard).

So the open/close freeze does not reproduce on this branch, and the one remaining sub-threshold hitch is the inherent first-build cost of a SwiftUI chart (not addressed here, and not cacheable on first render).

Scope / notes

This is a small, low-risk churn-reduction. It is not the main menu open/close freeze fix — recent main already addresses that via hosted-chart render signatures (#1384), card hosting-view harvest/recycling, height caching, and deferred rebuilds (#1376). This just removes one remaining source of needless menu invalidation that those caches then have to recover from.

🤖 Generated with Claude Code

Maintainer proof

Rebased head 6412dec8 passes 16 focused storage tests, make check, git diff --check, and clean autoreview. The focused Observation regression performs two identical scans over a real temporary Codex directory and verifies that the second scan does not republish observable storage state.

A freshly packaged release bundle rendered the storage row in Overview and completed three Peekaboo menu close/open cycles without crash, hang, slow menu operation, or slow chart render diagnostics. The temporary storage-display preference was restored afterward.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 11, 2026, 3:40 PM ET / 19:40 UTC.

Summary
The PR preserves content-identical provider storage footprints to avoid redundant observable writes while continuing to update refresh bookkeeping, and adds real-directory Observation regression coverage.

Reproducibility: yes. Current main unconditionally republishes the timestamp-bearing footprint dictionary, and the focused real-directory Observation regression directly verifies the second identical scan is a no-op after the patch.

Review metrics: 3 noteworthy metrics.

• Patch surface: 4 files, +98/-2. The change is tightly bounded to one observable update path, its value comparison, focused coverage, and release note.
• Focused validation: 16/16 storage tests. The relevant suite includes direct real-directory Observation regression coverage for the optimization boundary.
• Full validation: 3,634 tests, 0 failures. Maintainer proof reports a clean full suite on the reviewed implementation in addition to formatting and lint checks.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Next step before merge

• [P2] No repair is needed; maintainers should let current exact-head CI gate the reviewed branch and merge it through the normal PR path.

Security
Cleared: The patch is limited to local Swift state handling, tests, and release notes and introduces no dependency, secrets, permissions, artifact download, or supply-chain concern.

Review details

Best possible solution:

Merge the current exact head after its refreshed CI completes, retaining the dedicated content comparison and unconditional refresh-bookkeeping updates.

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

Yes. Current main unconditionally republishes the timestamp-bearing footprint dictionary, and the focused real-directory Observation regression directly verifies the second identical scan is a no-op after the patch.

Is this the best way to solve the issue?

Yes. A dedicated content comparator avoids changing the type's global Equatable contract, preserves all user-visible storage fields, and continues advancing scan signatures and timestamps.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 5cc8a248a457.

Label changes

Label justifications:

• P3: This is a low-risk performance cleanup that removes avoidable menu invalidation without changing visible storage semantics.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): Focused real-directory Observation evidence proves the changed publication behavior, and freshly packaged app proof shows the storage row plus repeated menu cycles without relevant slow-operation, crash, or hang diagnostics.
• proof: sufficient: Contributor real behavior proof is sufficient. Focused real-directory Observation evidence proves the changed publication behavior, and freshly packaged app proof shows the storage row plus repeated menu cycles without relevant slow-operation, crash, or hang diagnostics.

Evidence reviewed

What I checked:

• Current-main reproduction: Current main unconditionally filters and reassigns providerStorageFootprints on every completed scan before updating refresh metadata, so timestamp-only changes republish observable state. (Sources/CodexBar/UsageStore+ProviderStorage.swift:180, 5cc8a248a457)
• Exact patch surface: Relative to current main, the branch changes four expected files with 98 additions and 2 deletions: the update path, footprint model, focused tests, and release note. (Sources/CodexBar/UsageStore+ProviderStorage.swift:179, ce5b5951996f)
• Content comparison boundary: The helper compares every stored footprint content field—provider, total bytes, paths, missing paths, unreadable paths, and components—while intentionally excluding only updatedAt. (Sources/CodexBarCore/ProviderStorageFootprint.swift:56, ce5b5951996f)
• Refresh bookkeeping preserved: The observable dictionary assignment is guarded, but lastStorageRefreshSignature, lastStorageRefreshRequestKey, and lastStorageRefreshAt still advance after every accepted scan. (Sources/CodexBar/UsageStore+ProviderStorage.swift:195, ce5b5951996f)
• Focused regression: The added test creates a real temporary Codex directory, performs two identical scans, observes providerStorageFootprints, and verifies the second scan does not publish while storage data remains available. (Tests/CodexBarTests/ProviderStorageFootprintTests.swift:334, ce5b5951996f)
• Current-head provenance: The branch contains three substantive commits followed by an empty exact-head CI refresh commit; the storage implementation remains the reviewed patch after rebasing onto current main. (ce5b5951996f)

Likely related people:

• steipete: They reviewed and repeatedly rebased this branch, authored the current implementation commits, supplied focused and packaged-app proof, and recently carried adjacent hosted-menu performance work. (role: recent area contributor and reviewer; confidence: high; commits: 2550b590c4db, 8924fce2f10e, 7c0ed036e2e6; files: Sources/CodexBar/UsageStore+ProviderStorage.swift, Sources/CodexBarCore/ProviderStorageFootprint.swift, Tests/CodexBarTests/ProviderStorageFootprintTests.swift)
• jangisaac-dev: They authored the recently merged deferred menu-refresh rebuild work that addresses the same menu invalidation and tracking performance area. (role: adjacent area contributor; confidence: medium; commits: e97bfb0db9eb; files: Sources/CodexBar)
• soohanpark: The implementation commit preserves their co-authorship, and the PR contribution identified the timestamp-driven storage republish path and proposed the focused optimization. (role: behavior proposer and co-author; confidence: medium; commits: 2550b590c4db; files: Sources/CodexBar/UsageStore+ProviderStorage.swift, Sources/CodexBarCore/ProviderStorageFootprint.swift, Tests/CodexBarTests/ProviderStorageFootprintTests.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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]

Rebased onto current main (3c2d23d1) and pushed reviewed head 6412dec8.

Validation:

• swift test --filter ProviderStorageFootprintTests: 16 tests passed, including two identical real temporary-directory scans with Observation tracking
• make check: passed, 0 violations
• autoreview: clean, confidence 0.86
• ./Scripts/compile_and_run.sh: release bundle packaged, signed, launched, and remained running
• git diff --check: passed

Peekaboo/runtime proof with provider storage display temporarily enabled:

• Overview rendered the scanned storage row (Storage: 44 GB)
• repeated three close/open cycles completed without crash or hang
• redacted unified-log query found 0 slow menu operation or slow chart render diagnostics during the exercise
• screenshot: /tmp/codexbar-pr1416-storage.png
• the user setting was restored to disabled and the app restarted afterward

The focused regression is the direct proof for the optimization boundary: an unchanged second scan does not republish providerStorageFootprints, while refresh bookkeeping still advances.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Failed
• Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/27362219285
• Updated: 2026-06-11T16:40:54.038Z

[steipete]

Rebased onto current main and force-pushed exact reviewed head a262b299e4d870015791dbb20243c8a5753c09eb.

Proof:

• swift test --filter ProviderStorageFootprintTests — 16/16 passed
• make check — SwiftFormat/SwiftLint clean
• branch autoreview against current origin/main — no actionable findings

Waiting for exact-head CI before merge.

[steipete]

Exact-head maintainer proof for a262b299e4d870015791dbb20243c8a5753c09eb:

• Rebased onto current origin/main (b5edc46c0872cd0ecd431cbafc11ccb6062198ed).
• swift test --filter ProviderStorageFootprintTests: 16/16 passed.
• make check: passed; SwiftFormat and SwiftLint report zero violations.
• Branch autoreview against current origin/main: no accepted/actionable findings.
• Contributor authorship remains in the branch history; changelog credits @soohanpark.
• Exact-head CI: https://github.com/steipete/CodexBar/actions/runs/27370769398

[steipete]

Additional exact-head proof for a262b299e4d870015791dbb20243c8a5753c09eb:

• Full swift test: 3,634 tests across 412 suites passed; zero failures.

[steipete]

Landed in ad2a035f.

Proof on the rebased exact head ce5b5951:

• swift test --filter ProviderStorageFootprintTests — 16 passed
• make check — clean
• autoreview — clean (0.88)
• GitHub CI — macOS lint/full tests, Linux x64/arm64, and GitGuardian all green

Thanks @soohanpark!

[steipete]

Validated rebased exact head ce5b5951996f2007ae0a16decfd5c2d2ce6ea3c6.
Landed as ad2a035f66014985a11dd6b360cbb9f6d4e11d15.

• swift test --filter ProviderStorageFootprintTests (16 tests)
• regression test runs two real Codex storage scans over a temporary session tree
• second unchanged scan emits no providerStorageFootprints Observation update, so menuObservationToken is not awakened
• swift test (3,634 tests across 412 suites) on the source-identical rebased tree
• make check
• branch autoreview clean
• released/fictitious model-name gate clean
• exact-head GitHub CI is the authoritative full-suite gate