Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(tracing): Favour client options tracePropagationTargets #8399

Merged
merged 2 commits into from
Jun 27, 2023
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion packages/tracing-internal/src/browser/browsertracing.ts
Original file line number Diff line number Diff line change
Expand Up @@ -214,6 +214,9 @@ export class BrowserTracing implements Integration {
*/
public setupOnce(_: (callback: EventProcessor) => void, getCurrentHub: () => Hub): void {
this._getCurrentHub = getCurrentHub;
const hub = getCurrentHub();
const client = hub.getClient();
const clientOptions = client && client.getOptions();

const {
routingInstrumentation: instrumentRouting,
Expand All @@ -222,11 +225,13 @@ export class BrowserTracing implements Integration {
markBackgroundTransactions,
traceFetch,
traceXHR,
tracePropagationTargets,
shouldCreateSpanForRequest,
_experiments,
} = this.options;

const tracePropagationTargets =
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, does it make sense that the top-level options take precedence? 🤔 I think I would expect the options that are passed directly to the integration to "win", so:

this.options.tracePropagationTargets || (clientOptions && clientOptions.tracePropagationTargets);

? Not a big thing, as I don't expect this to happen too often, though :) So feel free to ignore.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah that's a fair perspective actually. Let's discuss this at our meeting.

Copy link
Member Author

Choose a reason for hiding this comment

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

Based on our meeting we've made two decisions.

  1. We'll be combining the arrays of both top level and integration set tracePropagationTargets
  2. We'll be emitting a warning when both values are set.

Copy link
Member Author

Choose a reason for hiding this comment

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

Detailed below I decided against the combining array approach, but added the warning in b098188

(clientOptions && clientOptions.tracePropagationTargets) || this.options.tracePropagationTargets;

instrumentRouting(
(context: TransactionContext) => {
const transaction = this._createRouteTransaction(context);
Expand Down
16 changes: 16 additions & 0 deletions packages/tracing-internal/test/browser/browsertracing.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -250,6 +250,22 @@ describe('BrowserTracing', () => {
tracePropagationTargets: ['something'],
});
});

it('uses `tracePropagationTargets` set by client over integration set targets', () => {
jest.clearAllMocks();
hub.getClient()!.getOptions().tracePropagationTargets = ['something-else'];
const sampleTracePropagationTargets = ['something'];
createBrowserTracing(true, {
routingInstrumentation: customInstrumentRouting,
tracePropagationTargets: sampleTracePropagationTargets,
});

expect(instrumentOutgoingRequestsMock).toHaveBeenCalledWith({
traceFetch: true,
traceXHR: true,
tracePropagationTargets: ['something-else'],
});
});
});

describe('beforeNavigate', () => {
Expand Down