Repository navigation
Conversation
…Safari iOS WebKit fails nextunique index cursors with "Unable to open cursor", so the recovery notice always reported storage as unavailable. Walk the index with a plain key cursor and continue past each project id instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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
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
On iOS Safari a persistent "Queue recovery storage is unavailable" banner appeared at the top of the app. The recovery notice lists projects with an index key cursor opened in the
nextuniquedirection, which iOS WebKit rejects withUnknownError: Unable to open cursor. The error was reported as unavailable storage on every 10-second refresh.The listing now walks the
byProjectindex with a plain key cursor and continues past each project id (continue(id + '\u0000')), so it still visits one key per project. This was the onlynextunique/prevuniquecursor in the frontend.Related Issues / Discussions
None.
QA Instructions
nextuniqueindex cursors fail on bothqueueRunsanddrafts, while plainopenKeyCursor,openCursorandgetAllKeyssucceed.queueRunJournal.browser.test.tsandQueueRecoveryNotice.browser.test.tsxpass in Chromium and in Playwright WebKit (35/35 each; WebKit via a temporary config withinstances: [{ browser: 'webkit' }]). The existing listing test records two runs for one project, so it covers duplicate skipping.nextuniquesucceeds there. On a fixture with two projects it and the new cursor walk return the same ids.tsc --noEmit,oxlint,oxfmt --checkclean.Review
No material findings. Desktop WebKit does not reproduce the iOS failure, so tests in either engine would not catch
nextuniquebeing reintroduced; a code comment records why it is avoided.Checklist
What's Newcopy (if doing a release after this PR)🤖 Generated with Claude Code