Conversation
…end seams ## Because - We cannot group or filter Sentry issues by area. `fxa.name` is the only tag applied centrally, and nothing writes down which tags the team is supposed to use. - One correction to the ticket: there is no `critical` tag in this repo. I looked. What we actually have is `fxa.name` in `tagFxaName.ts`, plus three ad-hoc tags in `fxa-auth-server`, `deleteStage` in `account-delete.ts` and `clientId` and `grantType` in `oauth/account-activity.ts`. Flagging it because the ticket is written against a version of the code that does not match what is there. ## This pull request - Adds `libs/shared/sentry/src/lib/utils/tags.ts` with the tag keys, a comment on each saying what it means, and an `applyCommonTags` helper. One place to check before you filter on a tag. - Applies the tags at the two existing `beforeSend` seams, `beforeSend.client.ts` and `beforeSend.server.ts`. Both used to call `tagFxaName` directly. - Exports `tags.ts` from the library index so callers can import the keys instead of retyping the strings. - Extends `beforeSend.client.spec.ts` to cover the three tags. Tags shipped: | Tag | Meaning | | --- | --- | | `fxa.name` | The FxA app or service that sent the event. Already applied; now defined in the tag module. Behaviour is unchanged. | | `fxa.runtime` | `browser` or `server`. Which side sent the event. | | `fxa.known_error` | True when the event carries an FxA `errno`, so an FxA API returned a handled error rather than an unexpected crash. | Three tags, not the five the ticket asks for. I would rather ship three I can define than five I have to hand-wave, because a vague tag turns into Sentry noise that nobody cleans up. Here is what I left out and why: - `sub-plat` needs a list of the endpoints subscription platform owns. That list does not exist in the code, and a path does not tell you who owns a route. Someone on the product side has to supply it. - `external` needs a signal that tells third-party errors apart from ours. I went looking in `libs/shared/sentry*`, `fxa-settings`, and `fxa-content-server/app/scripts/lib` for extension URL schemes, a deny list, an error class, anything. There is nothing, so implementing this would mean making up a heuristic and calling it a fact. - `email` has no seam here. Email is generated and sent server side, nowhere near `beforeSend`, and the email sender is out of scope for this change. ## Issue that this pull request solves Closes: FXA-5685
Contributor
There was a problem hiding this comment.
Pull request overview
Adds standardized Sentry tags for service name, runtime, and known FxA errors.
Changes:
- Introduces and exports common tag definitions and helper.
- Applies tags to Next.js client/server
beforeSendpaths. - Adds client and helper tests.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
utils/tags.ts |
Defines and applies common tags. |
utils/beforeSend.server.ts |
Tags server events. |
utils/beforeSend.client.ts |
Tags browser events. |
utils/beforeSend.client.spec.ts |
Tests tag behavior. |
index.ts |
Exports the tag API. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+7
to
+10
| /** | ||
| * The tags FxA applies to every Sentry event. Add a tag here before you set it | ||
| * anywhere, so the team can filter on a known set instead of guessing at keys. | ||
| */ |
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.
Because
fxa.nameis the only tag applied centrally, and nothing writes down which tags the team is supposed to use.criticaltag in this repo. I looked. What we actually have isfxa.nameintagFxaName.ts, plus three ad-hoc tags infxa-auth-server,deleteStageinaccount-delete.tsandclientIdandgrantTypeinoauth/account-activity.ts. Flagging it because the ticket is written against a version of the code that does not match what is there.This pull request
libs/shared/sentry/src/lib/utils/tags.tswith the tag keys, a comment on each saying what it means, and anapplyCommonTagshelper. One place to check before you filter on a tag.beforeSendseams,beforeSend.client.tsandbeforeSend.server.ts. Both used to calltagFxaNamedirectly.tags.tsfrom the library index so callers can import the keys instead of retyping the strings.beforeSend.client.spec.tsto cover the three tags.Tags shipped:
fxa.namefxa.runtimebrowserorserver. Which side sent the event.fxa.known_errorerrno, so an FxA API returned a handled error rather than an unexpected crash.Three tags, not the five the ticket asks for. I would rather ship three I can define than five I have to hand-wave, because a vague tag turns into Sentry noise that nobody cleans up. Here is what I left out and why:
sub-platneeds a list of the endpoints subscription platform owns. That list does not exist in the code, and a path does not tell you who owns a route. Someone on the product side has to supply it.externalneeds a signal that tells third-party errors apart from ours. I went looking inlibs/shared/sentry*,fxa-settings, andfxa-content-server/app/scripts/libfor extension URL schemes, a deny list, an error class, anything. There is nothing, so implementing this would mean making up a heuristic and calling it a fact.emailhas no seam here. Email is generated and sent server side, nowhere nearbeforeSend, and the email sender is out of scope for this change.Issue that this pull request solves
Closes: FXA-5685
Checklist
Put an
xin the boxes that applyHow to review (Optional)
utils/tags.tsfor the tag definitions, and the twobeforeSendfiles for where they are applied.tags.ts, thenbeforeSend.client.ts, thenbeforeSend.server.ts, then the spec.fxa.namekeeps its previous value on both seams.Screenshots (Optional)
Other information (Optional)
Worth knowing before you rely on the new tags: we have four separate copies of
beforeSendfloating around.browser.tsandnode.tsin this same library, plus thesentry-utils,sentry-browser,sentry-nestandsentry-nextcopies, each calltagFxaNamethemselves. None of them getfxa.runtimeorfxa.known_erroryet, so coverage is partial until those seams converge.node.tsalready has a@@todoto move ontoutils/beforeSend.server.ts. I left that convergence for a follow-up rather than widening this change.Verified locally:
beforeSend.client.spec.ts12 tests pass,tsc -p libs/shared/sentry/tsconfig.lib.json --noEmitis clean, andnx lint shared-sentrypasses.config-builder.spec.tshas one failure on this machine,util.isError is not a function, which is theintellogger against a newer Node and predates this change.