fix(@angular/build): add automatic corruption recovery in SQLite cache store - #34019
Merged
Merged
Conversation
…e store Abrupt process terminations (such as canceling a watch mode build or CI runner timeouts) can leave SQLite databases or their write-ahead logs in an inconsistent or corrupted state. Previously, corrupted database files or malformed pages caused subsequent builds to fail continuously until the cache directory was manually deleted. Additionally, uninitializable cache stores on read-only or restricted filesystems would throw errors during build initialization. Corrupted cache files (.db, .db-wal, and .db-shm) are now automatically removed and recreated upon initialization failure. If the cache cannot be initialized or recovered (such as on read-only filesystems or due to permission errors), the cache store gracefully disables itself. Cache operations subsequently degrade cleanly to cache misses, allowing builds to proceed successfully without error.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces robust error handling and recovery mechanisms to the SQLite-backed persistent cache store. It adds automatic recovery from database corruption (by deleting and recreating corrupted database files), graceful degradation when the database path is unwritable, and safe handling of locked databases. Additionally, it wraps cache operations in try-catch blocks to prevent fatal failures and introduces a configurable busy timeout. Comprehensive unit tests have been added to verify these behaviors. There are no review comments, so I have no feedback to provide.
clydin
added
the
action: review
alan-agius4
approved these changes
Sep 3, 2026
alan-agius4
added
action: merge
Member
Author
|
This PR was merged into the repository. The changes were merged into the following branches:
|
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
2 participants
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.
Abrupt process terminations (such as canceling a watch mode build or CI runner timeouts) can leave SQLite databases or their write-ahead logs in an inconsistent or corrupted state. Previously, corrupted database files or malformed pages caused subsequent builds to fail continuously until the cache directory was manually deleted. Additionally, uninitializable cache stores on read-only or restricted filesystems would throw errors during build initialization.
Corrupted cache files (.db, .db-wal, and .db-shm) are now automatically removed and recreated upon initialization failure. If the cache cannot be initialized or recovered (such as on read-only filesystems or due to permission errors), the cache store gracefully disables itself. Cache operations subsequently degrade cleanly to cache misses, allowing builds to proceed successfully without error.