Skip to content

Add fingerprint caching to restore and share commands#71

Merged
greynewell merged 1 commit intomainfrom
fix/restore-share-caching
Apr 8, 2026
Merged

Add fingerprint caching to restore and share commands#71
greynewell merged 1 commit intomainfrom
fix/restore-share-caching

Conversation

@greynewell
Copy link
Copy Markdown
Contributor

@greynewell greynewell commented Apr 8, 2026

Summary

Both restore and share were uploading the repo on every invocation with no cache check.

  • restore: caches the SupermodelIR response by git fingerprint under a restore analysis key; subsequent calls on an unchanged repo skip the upload
  • share: caches domain analysis under audit-domains key and impact under impact key — the same keys used by supermodel audit, so audit and share share results when run on the same codebase state; also deduplicated context.WithTimeout (was created once per API call, now once per runShare)

Test plan

  • go build ./... passes
  • go test ./... passes
  • Manual: supermodel restore twice — second call skips upload
  • Manual: supermodel audit then supermodel share — share skips both uploads (uses audit cache)

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Performance
    • Restore and share commands now cache analysis results, significantly speeding up subsequent runs on the same repository.
    • Share command improved timeout handling for enhanced reliability during analysis operations.

Both commands were uploading the repo on every call with no cache.

- restore: cache the SupermodelIR response by git fingerprint;
  subsequent calls without code changes skip the upload
- share: same caching; the domain analysis and impact results now
  share cache keys with `supermodel audit`, so running audit then
  share (or vice versa) requires only one upload per API type;
  also deduplicated context creation across both API calls

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 8, 2026

Caution

Review failed

Pull request was closed or merged during review

Walkthrough

These changes introduce repository fingerprint-based caching to the restore and share commands. When analysis results are requested, the system first checks a cache keyed by repository fingerprint, operation name, and build version. On cache hit, cached results are reused; on miss, API calls proceed and results are stored for future use.

Changes

Cohort / File(s) Summary
Restore command caching
cmd/restore.go
Adds fast-path cache lookup using repository fingerprint to bypass ZIP creation and API analysis calls; stores results to cache after successful analysis.
Share command caching
cmd/share.go
Implements fingerprint-keyed caching for both audit-domains analysis and impact analysis; refactors runShare, shareAnalyze, and runImpactForShare to accept fingerprint parameter and check/populate cache on each operation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

The changes follow a consistent, repetitive caching pattern (check cache → execute API → store result) applied across multiple functions. While there are signature modifications and cache key construction to verify, the logic is straightforward and the pattern is homogeneous, reducing cognitive load during review.

Possibly related PRs

Suggested reviewers

  • jonathanpopham

Poem

🔍 A fingerprint unlocks the cache,
No need to ZIP or call too fast,
Results remembered, swift and true,
Fast paths for both the old and new! ⚡

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: adding fingerprint-based caching to two commands.
Description check ✅ Passed The description covers the What and Why sections well, explaining the caching mechanism and shared cache benefits; test plan is mostly complete with build/test checks marked as done.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/restore-share-caching

Comment @coderabbitai help to get the list of available commands and usage tips.

@greynewell greynewell merged commit 4dad082 into main Apr 8, 2026
6 of 7 checks passed
@greynewell greynewell deleted the fix/restore-share-caching branch April 8, 2026 20:01
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