This workflow currently applies to Web and React browser errors only. It uses translated application source positions from private source maps. Native and React Native errors keep their existing grouping and resolution behavior.
Opt in to mapped grouping
Apps use legacy client-fingerprint grouping by default. An organization administrator can open the Web or React integration overview, find Error grouping, and enable Group errors by source location.
The setting admits only future eligible errors from that app. It does not backfill or regroup historical reports. Turning it off sends new errors back to legacy grouping; already admitted or queued work can still finish.
Mapped grouping also needs:
- An exact
appBuildon the captured report and a ready upload for that app/build. - Source-map processing enabled and the complete API processor deployment.
WEB_GROUPING_PROMOTION_WORKER_ENABLED=trueon the intended API worker and the persistedweb_grouping_promotion_control.pausedgate set tofalse. Both promotion controls are default closed; either one alone leaves the promotion queue dormant.
Before enabling active grouping, open Errors → Grouping comparison. It is a read-only sample of recent browser errors and shows whether each candidate is mapped, raw, pending, insufficient, or not yet computed. It also highlights sampled issues that may combine or separate. A zero in the sample is not proof that the whole app has no grouping changes.
Mapped keys use the normalized original file, line, and column. Stable source positions can converge the same error across differently minified builds. A compiler that changes original positions or maps several throw sites to one position can still split or combine issues unexpectedly. Raw, pending, and insufficient candidates never drive mapped merges.
Promotion preserves the captured report, Raw stack, report ID, webhook history, and total occurrence count. Existing emptied provisional issues remain available through their direct authorized URLs with grouping movement history. There is no automatic historical migration or manual merge/split tool.
Register release order
Release-aware resolution is available only for a positive-count mapped issue owned by one opted-in Web or React integration.
Open the integration overview and use the Releases card. An organization administrator registers:
- Build ID: the exact opaque value sent as SDK
appBuildand CLI--build. - Release order: a unique positive integer from 1 to 2,147,483,647.
Higher order means newer. Everframe does not infer order from semantic versions, build names, report arrival, source-map upload time, or registration time. Uploading maps does not register a release. Register each build before relying on its classification.
The current registry has no edit or delete action. You can register an older build later with a lower unused order, but registration does not rescan earlier occurrences. Parallel environments or release streams need separate integrations.
Mark a mapped issue fixed
Open the mapped issue, choose a registered build under Fixed in release, then select Mark fixed in release. Project members and administrators can mark the issue fixed.
Future mapped occurrences received after that action behave as follows:
| Occurrence build | Result |
|---|---|
| Registered below the fixed release order | The issue stays resolved and its count increases. |
| The fixed release or a higher registered order | The issue reopens as unseen and shows Regressed. |
| Not registered | The issue stays resolved; the uncertainty count increases. |
| Report received before the fix, mapped afterward | The issue stays resolved. |
The fixed release itself can regress: choosing it means another occurrence from that build is unexpected. The comparison uses server receipt time and explicit release sequence. Device clocks and semantic-version parsing are not involved.
Registering an unknown build later does not rewrite the current cycle. A future occurrence uses the registry available at that time. Missing build identity or maps can leave a report provisional, where it cannot be evaluated against a mapped issue’s fixed release.
Ordinary Resolve and Unresolve remain available and clear the selected release policy. Only the current release-resolution cycle is retained; this is not a complete regression audit timeline.
Send regression webhooks
An organization administrator can enable Regression alerts when creating a webhook subscriber or from that subscriber’s actions. The setting defaults off and applies only to future qualifying release-aware regressions.
Everframe sends a signed issue.regressed event through the existing durable
webhook queue. The event contains app, project, issue, event, report, resolution,
and fixed/regressed release identifiers and sequence numbers. It does not
contain the report body, exception message, source code, attachments, or user
identity.
Verify the standard webhook signature against the raw request bytes. Use the
event’s top-level id as the durable deduplication key: every subscriber and
retry for one resolution cycle receives the same logical ID and body. Delivery
is at least once; X-Everframe-Delivery-Id identifies one subscriber queue row,
while X-Everframe-Attempt changes across retries. See Webhooks
for signing and retry behavior.
Enabling alerts does not turn on mapped grouping, register releases, mark an issue fixed, or replay past regressions. Inbox/email delivery, native release policies, ownership, snoozing, automatic historical grouping, and optimized generic-cause presentation are outside the current completed scope.