feat(nuxt): Always add tracing meta tags by s1gr1d · Pull Request #13273 · getsentry/sentry-javascript

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

s1gr1d · 2024-08-08T07:51:13Z

Making sure tracing without performance works.

ref (SvelteKit): #13231

chargome

lgtm!

…13274) ref: #13273

Lms24 · 2024-08-08T13:26:17Z

- head.push(`<meta name="baggage" content="${dynamicSamplingContext}"/>`);
- }
+ const metaTags = getTraceMetaTags();
+ head.push(metaTags);


l: Not sure if this is problematic but I see we did this differently before: If nuxt expects one tag per array item we should split the return value from getTraceMetaTags() at \n since we usually return two tags separated by a \n.

I checked this and nuxt puts the html together in the correct way so this should be fine. But I would rather add a function parameter { options.asArray } to return it as array instead of adding \n and splitting it again afterwards.

I created a PR for this: #13293

As I closed the PR I just use the returned string now. This works with Nuxt as well and we don't have to split the string (slightly better performance).

Lms24

Thanks for explaining! LGTM!

Lms24 · 2024-08-12T09:24:55Z

+ ].join('\n');
+
+ // return value is mocked here as return values of `getTraceMetaTags` are tested separately (in @sentry/core)
+ (getTraceMetaTags as Mock).mockReturnValue(mockMetaTags);


I think that's fine, given the unit under test here is the Nuxt-specific addSentryTracingMetaTags function.
What we should do in the near future is to make sure our e2e tests cover distributed tracing behaviour. For example, we should check that
the sever-side request transaction and the client-side pageload transaction is connected by the same trace. This will validate that the trace meta tag injection generally works.
potential requests made on the client side to the server (thinking of API endpoint or data loading calls, whatever nuxt offers) are connected to the server side. This is probably easiest testable when making these calls during or directly after a navigation so that we can make sure a client-side root span exists.
I'm also working on a SvelteKit e2e test app that's specifically configured for tracing without performance. We could think about doing something similar for Nuxt but I wouldn't require it for the moment.

feat(nuxt): Always add tracing meta tags
f05848c

s1gr1d requested review from a team, Lms24 and chargome and removed request for a teamAugust 8, 2024 07:51

chargome approved these changes Aug 8, 2024
View reviewed changes

andreiborza mentioned this pull request Aug 8, 2024
ref(solidstart): Use core's getTraceMetaTags over own implementation #13274
Merged

andreiborza added a commit that referenced this pull request Aug 8, 2024
ref(solidstart): Use core's getTraceMetaTags over own implementation (#…
6cbc416
…13274) ref: #13273

Lms24 approved these changes Aug 8, 2024
View reviewed changes

s1gr1dand others added 3 commits August 9, 2024 14:55

Merge branch 'develop' into sig/nuxt-meta-tags
20db23c

Merge branch 'develop' into sig/nuxt-meta-tags
f096088

fix test
346a3ad

Lms24 approved these changes Aug 12, 2024
View reviewed changes

s1gr1d merged commit b29d771 into developAug 12, 2024

s1gr1d deleted the sig/nuxt-meta-tags branch August 12, 2024 09:30

This was referenced Sep 4, 2024
[Snyk] Upgrade @sentry/node from 8.22.0 to 8.26.0 Aam-Digital/account-backend#42
Closed
[Snyk] Upgrade @sentry/node from 8.22.0 to 8.26.0 Aam-Digital/replication-backend#158
Closed

q1blue mentioned this pull request Sep 7, 2024
[Snyk] Upgrade @sentry/react from 7.16.0 to 8.26.0 https-quantumblockchainai-atlassian-net/ossinsight#846
Open

FengShangWuQi mentioned this pull request Sep 8, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.26.0 FengShangWuQi/fengshangwuqi.github.io#1919
Closed

bagulm123 mentioned this pull request Sep 8, 2024
[Snyk] Upgrade: , , chart.js, classnames, cytoscape, typescript bagulm123/komiser#18
Open

KeeghanM mentioned this pull request Sep 12, 2024
[Snyk] Upgrade: , , , , , , next, posthog-js, posthog-node, react-chessboard, stripe KeeghanM/chess-training-app#94
Merged

This was referenced Sep 13, 2024
[Snyk] Upgrade: , , chart.js, classnames, cytoscape, next, typescript bagulm123/komiser#19
Open
[Snyk] Upgrade: , , , chart.js, classnames, cytoscape, next, typescript bagulm123/komiser#20
Open

onsails mentioned this pull request Sep 18, 2024
[Snyk] Upgrade: , , , next haqq-network/islamic-website#37
Open

mohamed-helmy22020 mentioned this pull request Sep 18, 2024
[Snyk] Upgrade @sentry/nextjs from 8.26.0 to 8.27.0 mohamed-helmy22020/banking#4
Open

gokulk16 mentioned this pull request Sep 23, 2024
[Snyk] Upgrade: , gokulk16/type-to-calculate-web#40
Closed

q1blue mentioned this pull request Sep 24, 2024
[Snyk] Upgrade @sentry/react from 7.16.0 to 8.27.0 https-quantumblockchainai-atlassian-net/ossinsight#893
Open

This was referenced Sep 24, 2024
[Snyk] Upgrade @sentry/browser from 8.25.0 to 8.27.0 gokulk16/type-to-calculate-web#42
Closed
[Snyk] Upgrade @sentry/browser from 8.25.0 to 8.28.0 gokulk16/type-to-calculate-web#44
Closed

FengShangWuQi mentioned this pull request Sep 27, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.28.0 FengShangWuQi/fengshangwuqi.github.io#1923
Closed

This was referenced Sep 27, 2024
[Snyk] Upgrade @sentry/react from 7.16.0 to 8.28.0 https-quantumblockchainai-atlassian-net/ossinsight#899
Open
[Snyk] Upgrade @sentry/react from 7.16.0 to 8.29.0 https-quantumblockchainai-atlassian-net/ossinsight#904
Open

bagulm123 mentioned this pull request Oct 1, 2024
[Snyk] Upgrade @sentry/react from 8.22.0 to 8.29.0 bagulm123/komiser#23
Open

q1blue mentioned this pull request Oct 1, 2024
[Snyk] Upgrade @sentry/react from 7.16.0 to 8.30.0 https-quantumblockchainai-atlassian-net/ossinsight#909
Open

KeeghanM mentioned this pull request Oct 3, 2024
[Snyk] Upgrade @sentry/react from 8.26.0 to 8.30.0 KeeghanM/chess-training-app#99
Merged