feat(init): cache project and DSN after create/init#730
Closed
feat(init): cache project and DSN after create/init#730
Conversation
createProjectWithDsn now seeds project_cache (by orgId:projectId and DSN public key) so the next command resolves from cache instead of hitting the API. Covers both `sentry init` and `sentry project create`. sentry init additionally seeds dsn_cache (keyed by directory) at both success paths (existing project + new project) so detectDsn() gets a cache hit instead of re-scanning source files. Follows the existing inline caching pattern used by resolveFromDsn and detectDsn — no new abstractions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨
Bug Fixes 🐛Init
Resolve
Upgrade
Other
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
Contributor
|
Contributor
Codecov Results 📊✅ 134 passed | Total: 134 | Pass Rate: 100% | Execution Time: 0ms 📊 Comparison with Base Branch
✨ No test changes detected All tests are passing successfully. ✅ Patch coverage is 100.00%. Project has 1640 uncovered lines. Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
- Coverage 95.28% 95.27% -0.01%
==========================================
Files 234 234 —
Lines 34644 34672 +28
Branches 0 0 —
==========================================
+ Hits 33008 33032 +24
- Misses 1636 1640 +4
- Partials 0 0 —Generated by Codecov Action |
betegon
force-pushed
the
feat/cache-project-on-create
branch
2 times, most recently
from
8578f60 to
be4d74d
Compare
The previous dsn_cache seeding in createSentryProject was broken: - No sourcePath (DSN not yet written to files at that point) - payload.cwd might not match projectRoot (detectDsn looks up by root) Move the cache seeding to after handleFinalResult in runWizard. At that point apply-patchset has already written the DSN to source files, so detectDsn finds it and caches with the correct projectRoot and sourcePath. The project_cache seeding in createProjectWithDsn (from the prior commit) still handles the API-avoidance side. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
After
sentry initorsentry project create, the resolved project and DSN data wasn't being saved to the local DB. This meant the next command (e.g.sentry issue list) had to re-scan files for the DSN and hit the API to resolve the project — even though all that info was just known.This seeds the same caches that
resolveFromDsnanddetectDsnpopulate on their slow paths, so subsequent commands get cache hits instead.Changes
createProjectWithDsninprojects.tsnow caches inproject_cache(by orgId:projectId and DSN public key). Covers bothsentry initandsentry project create.createSentryProjectinlocal-ops.tsnow caches indsn_cache(keyed by directory) at both success paths — existing project reuse and new project creation.All inline, matching the existing pattern in
resolve-target.tsanddetector.ts. Best-effort with try/catch so cache failures never break the command.Test Plan
sentry project create acme/foo node→ verifyproject_cachehas entrysentry init acme/my-app→ verify bothdsn_cacheandproject_cachepopulatedsentry issue listafter init → resolves from cache, no extra API call