fix(core): improve db connection initialization and error messages #33054
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
View your CI Pipeline Execution ↗ for commit 5a5a44a
☁️ Nx Cloud last updated this comment at |
| trace!("Verifying WAL mode still works"); | ||
|
|
||
| // Verify WAL mode works | ||
| match c.pragma_update(None, "journal_mode", "WAL") { |
There was a problem hiding this comment.
I'm a bit wishy-washy on this part, we'll chat over a call and look at it.
![nx-cloud[bot]](https://avatars.githubusercontent.com/in/80458?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nx Cloud has identified a possible root cause for your failed CI:
The test failure occurs during the Angular CLI project creation phase, specifically when Yarn attempts to install packages for a new Angular project. The error "Package install failed" indicates a problem with the package manager or package registry, not with the Nx database initialization code that was modified in this PR.
Analysis of the failure:
- The failing command is
@angular/cli@~20.3.0 new ng-proj... --package-manager=yarn - This is test setup code that runs before any Nx initialization
- The PR only modifies SQLite database initialization in Rust code
- No code path exists between database initialization and Angular CLI's package installation
The failure is classified as 'environment_state' because:
- External package manager failure (Yarn) during npm package installation
- No correlation between the PR's database initialization changes and Angular CLI/Yarn behavior
- The error occurs in test infrastructure setup, not in code being tested
- Likely causes: npm registry timeout, network issues, or Yarn/Corepack configuration problems in the CI environment
Similar failures on branch 33056 would help confirm this is a recurring environmental issue, but the tool returned no output, suggesting either no similar failures exist or the branch data is unavailable.
No code changes are warranted. This is an infrastructure/environment issue that needs investigation of the CI environment's package manager setup, network connectivity, or npm registry access.
A code change would likely not resolve this issue, so no action was taken.
🎓 To learn more about Self Healing CI, please visit nx.dev
leosvelperez
force-pushed
the
fix/misc-db-issues
branch
from
72602a2 to
5a5a44a
Compare
2 participants
Summary
Improved database initialization with better error handling, automatic recovery from stale files, and cache preservation during error recovery.
Changes Made
1. Iterative Retry Logic with Explicit State
Converted initialization from recursive calls to an iterative loop with a state flag (
cleaned_up_stale_files) that limits retries to 2 attempts. This makes retry conditions explicit and self-documenting while preventing potential stack overflow.2. Complete Auxiliary File Cleanup
Now removes all SQLite database files during cleanup (
.db,.db-wal,.db-shm) instead of just the main.dbfile. This prevents stale Write-Ahead Logging auxiliary files from causing initialization failures after version upgrades.3. Smart Compatible Database Handling
Compatible databases (matching version) are now reconfigured based on their current journal mode:
This preserves cached build outputs when possible while recovering from stale file issues automatically.
4. WSL1 Proactive Detection
Detects WSL1 environments by reading
/proc/versionand automatically uses DELETE journal mode instead of attempting WAL (which WSL1 doesn't support), preventing initialization failures.5. Enhanced Error Messages
Replaced generic error messages with context-specific, platform-agnostic guidance:
NX_NATIVE_LOGGING=trace) and reporting linkError messages work consistently across Windows, macOS, and Linux without suggesting commands that may not be available on the user's platform.
6. Code Quality Improvements
Extracted helper functions to reduce duplication:
query_journal_mode()- Query database's current journal modeset_busy_handler()- Configure connection-level busy handlerremove_wal_files()- Remove only WAL auxiliary filesremove_all_database_files()- Complete database cleanupcreate_io_error()/create_db_error()- Generate helpful error messagesProblems Solved
Stale WAL Files After Version Upgrades
Leftover
.db-waland.db-shmfiles from previous versions no longer cause initialization to fail. These files are now cleaned up automatically during initialization.Cache Loss on Recoverable Errors
When WAL mode issues occur on otherwise healthy databases, only auxiliary files are removed, preserving the main database and all cached build outputs. Full wipes only happen for genuine corruption or version mismatches.
WSL1 Compatibility
WSL1 environments now work without initialization failures by proactively detecting the environment and using DELETE mode instead of attempting WAL.
Performance Optimization
Databases in DELETE mode automatically attempt upgrading to WAL when the environment supports it (e.g., after moving workspace from network drive to local disk), providing better performance without manual intervention.
Poor Debugging Experience
Error messages now provide specific, actionable guidance based on the error type, helping users resolve issues without needing to ask for help.
Impact
nx resetfor stale file issuesRelated Issue(s)
Fixes #28640
Fixes #30856
Fixes #32894