fix: split IndexedDB open timing and cut its Sentry noise - #4145
Merged
Merged
Conversation
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.
Contributor
PR扫描结果依赖变更无依赖变更 |
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.
Why
The IndexedDB open instrumentation added in #4124 (shipped in 0.94.10) now produces about 62% of all 0.94.10 Sentry events:
indexeddb open slow: about 83k events / 44k usersindexeddb open timeout: about 20k events / 12k usersWhat the data shows so far:
db_blocked=False, so none of them is an upgrade stuck behind another context.Android 10; KUA.elapsedstarts when the module is evaluated. The.thencallback can't run until the rest of the background bundle has finished evaluating and the event loop is free. Soelapsedcan'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_elapseddb_open_loop_lagdb_open_after_first_tickdb_open_context:background/popup/notification/ …The duration tags use buckets
lt_1s … gte_60s. Exact milliseconds stay inextra, since Discover can't aggregate extra fields.Report after a timeout. A new message
indexeddb open resolved after timeoutfires 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%.
sampleRategoes intoextra; 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
tsc. Not yet run in a browser or on a device.