You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(push): release SQLite queue when transactions cannot start - #22208
A failed SQLite write lock could leave push registration, delivery bookkeeping, and shutdown waiting forever. Later operations now proceed when the lock becomes available.
What Changed
Move BEGIN IMMEDIATE inside the existing cleanup boundary so the transaction always releases its queue slot. Only roll back a transaction that actually started.
Why
The previous failure path left an unresolved promise retaining every later queued operation. Reusing the existing finally preserves serialization and avoids new retry or database policies.
Linked Issue
N/A — found during the requested local memory audit; its tracker stays local.
Visual Proof
N/A — resource lifetime and queue admission changes have no visual change. Regression tests provide before/after evidence.
Testing
A regression using two real SQLite connections fails by timeout on the original code and passes after the fix. It repeats lock failure and recovery ten times, then closes the database.
Closing as fully superseded on current main (1a723194c3294298c8db106105d1be226823ae9c). I read the complete two-file patch, including the real-SQLite lock failure/recovery regression.
Push now delegates openPushDatabase() to @orca-cloud/cloud-database (shared in #33714). Its SqliteDatabase.transaction() places BEGIN IMMEDIATE inside the outer try/finally that releases the queue promise. The inner operation/COMMIT try/catch starts only after BEGIN succeeds, so BEGIN failure never runs ROLLBACK and always releases the queue. Queries and close continue to await the serialized tail. The current cloud/apps/push/src/sqlite-transaction-queue.test.ts also covers lock refusal followed by usable work and close.
The production paths are unchanged between the audited checkout and the current main commit above. The queue-release and conditional-rollback behavior this PR repairs is already implemented; there is no remaining distinct production fix to carry forward. This was a read-only source comparison; no tests or service launches were run.
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
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.
ELI5
A failed SQLite write lock could leave push registration, delivery bookkeeping, and shutdown waiting forever. Later operations now proceed when the lock becomes available.
What Changed
Move
BEGIN IMMEDIATEinside the existing cleanup boundary so the transaction always releases its queue slot. Only roll back a transaction that actually started.Why
The previous failure path left an unresolved promise retaining every later queued operation. Reusing the existing
finallypreserves serialization and avoids new retry or database policies.Linked Issue
N/A — found during the requested local memory audit; its tracker stays local.
Visual Proof
N/A — resource lifetime and queue admission changes have no visual change. Regression tests provide before/after evidence.
Testing
ORCA_BACKGROUND_LAUNCH=1; PostgreSQL code unchanged.AI Disclosure
Implemented and reviewed with Codex.
Review
Self-reviewed ownership, failure paths, and retained-resource bounds.
Agent skill upstream boundary
Notes
No wire format, platform-specific process handling, Git-provider behavior, or workspace-kind change.
Checklist