Skip to content

[Onyx] Edge on Windows: every IndexedDB read and write fails with UnknownError: Internal error., leaving the web app unusable #102272

Open
Open
[Onyx] Edge on Windows: every IndexedDB read and write fails with UnknownError: Internal error., leaving the web app unusable#102272
Assignees
sosek108Pujan92mountinymkhutornyi
Labels
ReviewingHas a PR in reviewTaskWeeklyKSv2

Description

@melvin-bot
melvin-bot
bot
opened on Sep 25, 2026

Problem

A user on Edge 153 (Windows 10, x64) can't use New Expensify on web. The app shows "Something went wrong… we have not been able to load all of your data." API calls such as OpenApp, Search and OpenReport succeed, so the failure is in local storage. The same account works in the iOS app.

What the client logs show

Between 07:32 and 09:26 UTC on 2026-09-25, the client logged these errors:

  • [Onyx] Failed to load data from storage during init. The app will boot with default key states only. Error: UnknownError: Internal error. (5 times, once per app load)
  • [Onyx] IDB error not recoverable at the connection layer, propagating (about 2,175 times), with dbName: 'OnyxDB', storeName: 'keyvaluepairs', errorClass: 'unknown' and errorMessage: 'Internal error.'
  • [Onyx] Unclassified storage error. provider: IDBKeyValProvider. name: UnknownError. message: Internal error. (243 times on setWithRetry and 58 times on multiSetWithRetry)
  • [Onyx] Storage operation failed after 5 retries (the same 243 and 58). Every write failed on all six attempts, from retryAttempt: 0/5 through 5/5.

The account has no storage errors in the logs before that morning, although the user said the problem had lasted two days.

Observations

  • Reads fail as well as writes. The app starts with default state on every load, so reloading doesn't help.
  • The error is classified as unknown. Onyx treats it as not recoverable at the connection layer, so no reconnect or recovery happens, and every write uses up its retries.
  • The user sees a generic error with no hint to clear site data or switch browsers.

Expected

When IndexedDB fails for both reads and writes with a non-recoverable UnknownError, the app should:

  1. Detect the failure.
  2. Try to recover, for example by deleting and recreating OnyxDB, or fall back to in-memory storage.
  3. Tell the user how to recover.

Workaround

Clear site data for new.expensify.com in Edge, or use another browser or the mobile app.

Related

Reported in Slack.

Issue OwnerCurrent Issue Owner: @mkhutornyi

Activity

  1. mountiny
    assigned
    sosek108
    on Sep 25, 2026
  2. mountiny
    added
    DailyKSv2
    Task
    on Sep 25, 2026
  3. mountiny
    added this to [#whatsnext] #qualityon Sep 25, 2026
  4. mountiny
    moved this to CRITICAL in [#whatsnext] #qualityon Sep 25, 2026

  5. sosek108 commented on Sep 25, 2026

    @sosek108
    sosek108
    on Sep 25, 2026
    Contributor

    UnknownError: Internal error

    On Edge (Windows) it means that we have a problem with persistence:

    • full disk
    • database left in error state after unclean shutdown of the browser / system
    • another process holding the directory
    • antivirus, disk cleaners.

    We don't know what the cause is. Full disk is covered only on native (DISK_PRESSURE in classifySQLiteError). On web nothing covers any of these. StorageCircuitBreaker handles only quota errors (CAPACITY).

    From source code analysis we know that the connection to the database is established. The error doesn't carry Chromium's open-failure wording (Internal error opening backing store, which we map to FATAL), so classifyError maps it to UNKNOWN. So currently what Onyx does is retry each operation 5 times (6 attempts) and then give up. If the problem is with a faulty database this will not work.

    What may work here

    There are three things that could work in this case:

    1. restart the database by remove / recreate
    2. degrade to MemoryOnlyProvider
    3. both. First restart the database, then degrade if still faulty.

    The caveat is that we would map every UnknownError to this solution. We can narrow it by matching name: UnknownError + message: Internal error. only.

    Proposal of next steps

    Redesign consecutive error handling in the application. Currently there are several cases:

    1. Degrade to MemoryOnlyProvider - when IndexedDB doesn't exist at all (UNAVAILABLE). Merged to Onyx, but E/App is still not bumped.
    2. Reconnect - when the cached connection is stale (TRANSIENT, once per operation) or the backing store is corrupted (FATAL, up to 3 times).
    3. Do nothing - when we encounter known unrecoverable issues (the write is dropped).
    4. Retry every operation - when we encounter an UNKNOWN error we retry every operation 5 times and then give up.

    When IDB operations fail repeatedly with no success, we could do until succeeded:

    1. try to reconnect to the database
    2. recreate the database (delete and create a new one)
    3. if the delete fails, we degrade to MemoryOnlyProvider

  6. fabioh8010 commented on Sep 28, 2026

    @fabioh8010
    fabioh8010
    on Sep 28, 2026
    Contributor

    @sosek108 Have you analysed Fullstory sessions and VictoriaLogs of the user during the timespan of these errors? Do we know what they were trying to do or maybe there were another errors happening in the app?

    Could we also analyse the general amount of UnknownError: Internal error. we had in the last 30 days, which browsers were, etc?

  7. melvin-bot
    added
    Overdue
    on Sep 28, 2026

  8. sosek108 commented on Sep 28, 2026

    @sosek108
    sosek108
    on Sep 28, 2026
    Contributor

    Do we know what they were trying to do or maybe there were another errors happening in the app?

    This error occured just after log in. User was able to signin and on home Page he saw the popup:

    Image

    No other coexisting errors in the logs. A session before (4 days earlier) user was permitting normal operations, including data export.

    Sentry issue analysis for last 30 days:

    • 13 users / 943 events
    • most events have no user attached (83%) suggesting it fires before the session loads
    • Chromium only: Chrome 59%, Edge 41%
    • no stack trace
    • 67% are Windows, 32% Mac OS. Another proof this is only browser issue
  9. melvin-bot
    removed
    Overdue
    on Sep 28, 2026

  10. fabioh8010 commented on Sep 29, 2026

    @fabioh8010
    fabioh8010
    on Sep 29, 2026
    Contributor

    I checked the [Onyx] Failed to load data from storage during init. The app will boot with default key states only. Error: UnknownError: Internal error. logs on VictoriaLogs and looks like most of the cases can be solved with a simple closing/reopening of the IndexedDB connection.

    @sosek108 do you think this approach would be enough? We should target exclusively UnknownError: Internal error. error class.

  11. sosek108 commented on Sep 29, 2026

    @sosek108
    sosek108
    on Sep 29, 2026
    Contributor

    I think this is least we should do. I'll prepare the PR for it

  12. melvin-bot
    added
    ReviewingHas a PR in review
    WeeklyKSv2
    and removed
    DailyKSv2
    on Sep 29, 2026

  13. sosek108 commented on Sep 29, 2026

    @sosek108
    sosek108
    on Sep 29, 2026
    Contributor

    Here is draft PR: Expensify/react-native-onyx#853

  14. sosek108 commented on Sep 30, 2026

    @sosek108
    sosek108
    on Sep 30, 2026
    Contributor

    PR is open for review

  15. mountiny
    assigned
    mountiny
    and
    Pujan92
    on Sep 30, 2026

  16. sosek108 commented on Oct 1, 2026

    @sosek108
    sosek108
    on Oct 1, 2026
    Contributor

    PR is merged, but @Pujan92 validly pushed back, that this does not fix the issue for our reported user. Expensify/react-native-onyx#853 (comment)

    This is in compliance w/ my earlier comment where I proposed this chain.

    When IDB operations fail repeatedly with no success, we could do until succeeded:
    try to reconnect to the database
    recreate the database (delete and create a new one)
    if the delete fails, we degrade to MemoryOnlyProvider

    After some thinking I would drop recreate the database and do this:

    When Internal error occurs Onyx:

    1. try to reconnect to the database (already in place)
    2. check if this helped. And if not we fallback to MemoryOnlyProvider (this Provider is already implemented, we need to wire this case to the provider)

    PoC drafted here: Expensify/react-native-onyx#854 (needs polishing)

    cc: @fabioh8010

  17. sosek108 commented on Oct 1, 2026

    @sosek108
    sosek108
    on Oct 1, 2026
    Contributor
    Image

  18. sosek108 commented on Oct 8, 2026

    @sosek108
    sosek108
    on Oct 8, 2026
    Contributor

    The second PR is ready for review: Expensify/react-native-onyx#854

    cc: @Pujan92

  19. mountiny
    assigned
    mkhutornyi
    on Oct 9, 2026

  20. mountiny commented on Oct 9, 2026

    @mountiny
    mountiny
    on Oct 9, 2026
    Contributor

    Assigned @mkhutornyi to the PR since there was no action from the C+ there

  21. Pujan92 commented on Oct 9, 2026

    @Pujan92
    Pujan92
    on Oct 9, 2026
    Contributor

    Oh, I missed this notification and bcoz of react-native pr don't show in K2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

ReviewingHas a PR in reviewTaskWeeklyKSv2

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions