fix(storage): reopen the IDB connection on UnknownError: Internal error.

[sosek108]

Details

Chromium reports a class of persistence failures as UnknownError whose message is exactly Internal error., with no cause attached. Our classifier only recognized the Internal error opening backing store for indexedDB.open. wording as FATAL, so this one fell through to UNKNOWN. UNKNOWN is owned by the operation layer, which means retryOperation burned its whole budget (6 attempts per operation) while the connection layer never reopened the database. On the affected sessions that produced a write that never landed and an app that booted with default state on every reload.

This PR maps error to FATAL only when name === 'UnknownError' and the message is exactly Internal error., so the connection layer's existing budgeted heal (drop the cached connection, reopen, retry, up to 3 attempts, reset on success) runs for it. If the reopen does not help, the existing IDB heal: backing store error — heal budget exhausted, giving up alert fires and the operation layer skips the retry quietly, as it already does for every other FATAL error.

Matching is exact on purpose: no other UnknownError wording is pulled into the reopen path, and no other error name matching Internal error. is either.

The heal log now carries errorMessage, which is what makes the two FATAL wordings separable in VictoriaLogs. That is what tells us, after this ships, how much of the remaining volume the reopen actually recovers, and whether escalating to a delete-and-recreate or a memory-only fallback is warranted.

Related Issues

Expensify/App#102272

Linked E/App PR

Expensify/App#102530

Automated Tests

• classifyErrorTest: the exact wording classifies as FATAL (with and without the trailing period); nearby wordings (Internal error while reading blob) and a different name with the same message (SyntaxError: Internal error.) stay UNKNOWN.
• createStoreTest: a transaction failing with Internal error. heals by reopening and the read succeeds on the fresh connection, and the heal log carries the message.
• onyxUtilsTest: the same error at the operation layer skips the retry instead of exhausting the budget, and emits no Unclassified storage error alert.

All four assertions fail against main and pass with the change. Full unit suite passes (697 tests).

Manual Tests

To be verified against the linked E/App PR.

Author Checklist

• I linked the correct issue in the ### Related Issues section above
• I linked the corresponding Expensify/App PR in the ### Linked E/App PR section above, and verified this change against it (E/App CI passed and manual testing completed)
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android / native
  • Android / Chrome
  • iOS / native
  • iOS / Safari
  • MacOS / Chrome / Safari
• I verified there are no console errors
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants are defined as such

[sosek108]

@fabioh8010 sorry, this was not meant to be reviewed yet. My agent went rogue and published PR without consent :/

[sosek108]

@fabioh8010 it's ready for your review. I've simplified/removed the comments and removed unnecessary code changes that were previously added

[Pujan92]

@sosek108 isn't an app refresh giving a new DB connection(with that Refresh and try again button should work for users)?

[Pujan92]

LGTM! One doubt regarding refresh which isn't blocker for this PR.

[mountiny]

Thanks for addressing this fast

[mountiny]

@sosek108 can you make sure the checklist is full nect time please? Thanks

[os-botify]

🚀 Published to npm in 3.0.118 🎉

[melvin-bot]

@mountiny looks like this was merged without a test passing. These checks had not passed on 4d9ad74 when it was merged:

• validate-checklist (failure)

Please add a note explaining why this was done and remove the Emergency label if this is not an emergency.

[sosek108]

Yes, a reload opens a fresh connection, so in the cases where a reopen fixes it, "Refresh and try again" would fix it too. The difference is who triggers it and what's lost before then:

• Refresh is manual and late. By the time the user sees the error, Onyx has already booted with default key states, and every write in the meantime has used up its 6 attempts and been dropped. The in-session reopen runs on the first failing transaction, so the operation retries on the new connection and the user never sees anything.
• Refresh didn't help the reported user. They hit Failed to load data from storage during init 5 times, once per load. Their database stays broken across connections, so neither a reload nor this PR fixes it. now this situation carries errorMessage: 'Internal error.'.

That log is how we'll tell the two groups apart in VictoriaLogs: sessions where the reopen recovers, and sessions that need delete-and-recreate or the MemoryOnlyProvider fallback, which could be the next step in the issue.

[mountiny]

Removing Emergency, C+ tested the PR and works on the checklist over in the App PR Expensify/App#102530 (comment) and the author added the checklist when prompted as well