Skip to content

feat(develop): Allow to pass user_agent as browser context - #13205

Closed
mydea wants to merge 1 commit into
masterfrom
fn/develop-docs-user-agent
Closed

feat(develop): Allow to pass user_agent as browser context#13205
mydea wants to merge 1 commit into
masterfrom
fn/develop-docs-user-agent

Conversation

@mydea

@mydea mydea commented Apr 2, 2025

Copy link
Copy Markdown
Member

Related to #13203

Today, the browser context is inferred in relay from event.request.headers['user-agent']. This is slightly weird in the context of a browser event, as the page is not really the request - we want to replace this with something more explicit.

In order to make this possible, we propose to allow client SDKs to send a partial browser context with only user-agent, and have relay infer the rest of the data from this, if it exists (instead of from event.request).

@mydea
mydea requested review from a team, cleptric and lforst April 2, 2025 14:02
@mydea mydea self-assigned this Apr 2, 2025
@vercel

vercel Bot commented Apr 2, 2025

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
develop-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 2, 2025 2:06pm
2 Skipped Deployments
Name Status Preview Comments Updated (UTC)
changelog ⬜️ Ignored (Inspect) Apr 2, 2025 2:06pm
sentry-docs ⬜️ Ignored (Inspect) Apr 2, 2025 2:06pm

@lforst lforst left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sgtm. Before we merge this we should actually implement this in Relay.

@mydea

mydea commented Apr 2, 2025

Copy link
Copy Markdown
Member Author

After talking with @Dav1dde we will actually not do that, because it is hard for relay to partial-update contexts. Instead, relay can use the user-agent from the browser envelope request itself, which should already be here - which is great, because it means the SDK does not need to do/send anything 💪

@mydea mydea closed this Apr 2, 2025
@lforst

lforst commented Apr 3, 2025

Copy link
Copy Markdown
Contributor

After talking with @Dav1dde we will actually not do that, because it is hard for relay to partial-update contexts. Instead, relay can use the user-agent from the browser envelope request itself, which should already be here - which is great, because it means the SDK does not need to do/send anything 💪

Scary. In the case of tunneling this information is lost. "Hard for relay to partially update contexts" also seems a bit ridiculous.

@cleptric cleptric left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We actually need to figure out how this will be handled in Relay fist.

  • If there is no browser context, Relay creates one
  • How does the presence of a user_agent fit in in the current behavior
  • How do we merge partial context

@lforst lforst self-assigned this Apr 8, 2025
@lforst

lforst commented Apr 8, 2025

Copy link
Copy Markdown
Contributor

I think the plan of action for relay is:

  • Drop the requiredness of the name field in the Browser context.
  • If name and version are not defined and user_agent is defined, backfill name and version in the browser context.
  • Keep creating browser context when there is none and the Request interface contains a user agent.

@mydea

mydea commented Apr 23, 2025

Copy link
Copy Markdown
Member Author

@cleptric are we good with merging this? I think we agreed that this makes sense from a spec-perspective, or should we merge the relay change before we merge this in develop docs?

@cleptric cleptric left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with merging this, if we don't forgot to also add it in Relay 😬

@mydea mydea closed this Apr 13, 2026
@github-actions github-actions Bot locked and limited conversation to collaborators Apr 29, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants