The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. Resource failures and script exceptions have different window error shapes, and Promise reasons may not be Error. Normalize kind, code, stack fingerprint, and release first.
Observability should locate the failing stage, affected sessions, and whether impact is growing. Events use allowlisted low-cardinality dimensions; payloads, secrets, and complete network identity stay out.
Make the implementation decisions explicit
Write the following choices as reviewable rules instead of scattering them across callbacks and UI conditions. Explicit rules make scaling, compatibility, and diagnosis less dependent on guesswork.
- Allow controlled same-origin stacks, strip URL query and fragments, clean messages, aggregate fingerprints in a window, and send a small beacon batch on unload.
- Define success, degraded, cancelled, and failed terminal states before UI, storage, and metrics consume the same state.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Collecting Browser Exceptions, Promise, Resource, and CSP Errors is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
An abnormal path is more than an error banner. It decides how in-flight work stops, how the peer learns the outcome, what residue remains, and whether the next operation inherits it.
- An error in the handler recursively reports itself, while response bodies or DOM snapshots leak chat, filenames, and connection secrets.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- Ideal-size tests miss large files, long sessions, and concurrency that cross hidden limits and cause cascading failure.
How to verify it before release
A release gate combines deterministic regression, randomized timing, and real browser pairs. Preserve the seed and state trace from every failure as a permanent replay case.
- Trigger sync exceptions, string rejections, 404 scripts, a 521 API, cross-origin scripts, and CSP violations; verify classification, dedupe, redaction, and offline recovery.
- Run one hundred start, fail, retry, and cancel cycles; handles, listeners, queues, and temporary data must return to baseline.
- Before release, record success rate, p50/p95/p99 latency, error classes, and resource high-water marks with explicit rollback thresholds.
The release standard is practical: the normal path is fast, abnormal paths converge, recovery never overrides an explicit user decision, and operators can diagnose faults from limited, privacy-safe evidence.