Skip to content

fix: split IndexedDB open timing and cut its Sentry noise - #4145

Merged
cs1707 merged 1 commit into
developfrom
fix/indexeddb
Sep 30, 2026
Merged

cs1707 merged 1 commit into
developfrom
fix/indexeddb

Conversation

@cs1707

@cs1707 cs1707 commented Sep 29, 2026

Copy link
Copy Markdown
Collaborator

Why

The IndexedDB open instrumentation added in #4124 (shipped in 0.94.10) now produces about 62% of all 0.94.10 Sentry events:

  • RABBY-5MX indexeddb open slow: about 83k events / 44k users
  • RABBY-5MY indexeddb open timeout: about 20k events / 12k users

What the data shows so far:

  • Every one of these events has db_blocked=False, so none of them is an upgrade stuck behind another context.
  • About 98% come from the background service worker; UI pages send only a small share.
  • Android is heavily over-represented: 16.5k users with a slow event, against 2.5k users with any other error. These are Chromium builds that run extensions, with the reduced Android 10; K UA.

elapsed starts when the module is evaluated. The .then callback can't run until the rest of the background bundle has finished evaluating and the event loop is free. So elapsed can't tell a slow IndexedDB apart from a busy service worker cold start. There is a second gap: once a timeout is reported, the one-shot guard hides whether the open ever finished. That means the timeout issue can't tell a hang from an open that only took more than 15s.

What changed (src/db/index.ts)

  • Split the timing. A setTimeout(0) scheduled next to the open records when the event loop first comes free. Reports now carry these tags:

    • db_open_elapsed
    • db_open_loop_lag
    • db_open_after_first_tick
    • db_open_context: background / popup / notification / …

    The duration tags use buckets lt_1s … gte_60s. Exact milliseconds stay in extra, since Discover can't aggregate extra fields.

  • Report after a timeout. A new message indexeddb open resolved after timeout fires when an open settles after the timeout. Real hangs ≈ timeouts − late resolves. Some of that gap can also be service workers that were torn down before the open finished.

  • Sample slow at 5%. sampleRate goes into extra; multiply counts by 20 to get totals. Timeout, late-resolve and blocked reports stay unsampled, so the subtraction above still holds.

  • Mute the timing messages on Android (UA match). A failed open is still captured as an exception on every platform.

Reviewer notes

  • Nothing here touches app behaviour. The changes only affect what gets sent to Sentry.
  • On Android, slow and timeout counts will drop sharply after release. Dashboards that compare against 0.94.10 should filter on release.
  • The new message creates one new Sentry issue.
  • Checked with eslint, prettier and tsc. Not yet run in a browser or on a device.

The open instrumentation from #4124 now accounts for ~62% of 0.94.10
events, and elapsed alone can't tell a slow IndexedDB from a background
bundle that hasn't yielded the event loop yet.

- Record when the event loop first comes free after the open starts and
  report loop lag and post-tick time separately, as bucketed tags that
  Discover can aggregate, plus the calling context (background / page).
- Follow a timeout with "indexeddb open resolved after timeout" when the
  open eventually settles, so real hangs = timeouts - late resolves.
- Sample "indexeddb open slow" at 5%; timeouts stay unsampled.
- Mute the timing messages on Android, where weak hardware and a frozen
  background dominate the numbers. Open failures are still captured.
@ddddhm1234

Copy link
Copy Markdown
Contributor

PR扫描结果

依赖变更

无依赖变更

@cs1707
cs1707 merged commit 450ea24 into develop Sep 30, 2026
4 of 5 checks passed
@cs1707
cs1707 deleted the fix/indexeddb branch September 30, 2026 04:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants