add failing bug-report test: a rejected bulkWrite permanently wedges the incremental-write queue - #9026
Open
kilbot wants to merge 1 commit into
Open
add failing bug-report test: a rejected bulkWrite permanently wedges the incremental-write queue#9026kilbot wants to merge 1 commit into
kilbot wants to merge 1 commit into
Conversation
…the incremental-write queue
pull Bot
pushed a commit
to HumpfTech/monorepo
that referenced
this pull request
Sep 1, 2026
…writes Upstream rxdb bug (our failing-test PR: pubkey/rxdb#9026): IncrementalWriteQueue.triggerRun() has no try/finally, so one rejected storage bulkWrite leaves isRunning=true forever - the failing caller and every later incrementalModify() on that collection hang, never settling, with only an unhandledRejection as a trace. Our sync scheduler persists task state through incrementalModify, so a single transient storage failure could silently freeze it (candidate mechanism for wedge shape b, proven in isolation, not yet confirmed in CI). pnpm patch on rxdb@17.4.0 (both esm and cjs builds): wrap triggerRun's body in try/catch/finally - reject the taken-over items so callers observe the error, always reset isRunning. Identical fix verified green against upstream's own bug-report test harness before applying here. Pin test (packages/database/src/rxdb-incremental-write-patch.test.ts) goes through the public API and was verified red-first on unpatched rxdb (caller never settles, jest timeout) then green on the patch; it also proves the queue recovers for the write after the failure. Tested: pin test 1/1; packages/database jest 456/456; sync-engine vitest 1688/1690 (2 skipped) with --maxWorkers=2; lint 0; typecheck 0.
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.
Failing bug-report test, per the template instructions.
The bug: one rejected storage
bulkWritepermanently wedgesIncrementalWriteQueue.triggerRun()setsisRunning = truebut only resets it at the end of the happy path — there is no try/finally. IfstorageInstance.bulkWrite()rejects (a transient io error),triggerRun()exits withisRunningstilltrue. The items of that run are never rejected, and every lateraddWrite()parks behind theisRunningearly-return. After a single transient storage failure, everyincrementalModify()/incrementalPatch()on that collection hangs forever, and the only trace is an unhandledRejection.The test: insert a doc, make the next
bulkWritewith context'incremental-write'reject once, callincrementalPatch()twice. Expected: the first call rejects with the storage error, the second succeeds. Actual: neither promise ever settles.I also verified the test passes when
triggerRun()'s body is wrapped in try/finally (resetisRunning, reject the taken-over items — mirroring the existingpreWritefailure handling), so the test detects the fix.