ref(browser): Add protocol attributes to resource spans

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.

[Zen-cronic]

Resolves#12395

Changes made:

• Relocated extractNetworkProtocol util and its unit test to browser-utils.
• Modified browserMetrics test to assert the new metadata.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[Zen-cronic]

This prop is needed even if the metadata is not asserted, otherwise this line throws due to undefined value:

sentry-javascript/packages/browser/src/tracing/request.ts

Line 241 in a67d3ca

for(constcharofnextHopProtocol){

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

Hey @Zen-cronic, once again, thanks for contributing! :D

I took the liberty to refactor the unit tests a bit and make the integration test for resource spans a bit more robust (see comments).

[Lms24]

Yeah I was a bit worried about this but I think it's okay. MDN classifies the nextHopProtocol prop as widely available and we previously treated it as such when adding timing info to fetch request spans. So it's okay to add this I think. If we get reports, we can still safeguard usage later.

[Lms24]

I added this last case here because according to MDN, nextHopProtocol will be empty for cross-origin resource requests where the responses don't contain a Timing-Allow-Origin header.

I was briefly debating changing the implementation to {name: 'unknown', version: 'unknown'} for consistency but then realized that this doesn't let us distinguish between the cross origin case and when we simply don't recognize the protocol. So let's leave it as-is for now.

[Lms24]

I was hoping this would actually be populated but looks like PlayWright/Chromium Headless emits a '' despite me returning a Timing-Allow-Origin: * header. Same goes for the deliveryType property which follows a similar pattern

[Zen-cronic]

gotcha, i tried asserting the network.protocol.name and version here as well. But they came out to be unkown. And the properties were more comprehensively tested in the unit test, so i didn't add them here.
thanks for updating the integration test for better coverage!

[Lms24]

Yeah, I'm also not super happy about this but it looks like some browser or playwright bugs might be responsible for the ''. Coincidentally, we opened #15164 where it seems like at least some changes were made to cross origin performance entry data. So maybe this actually solves itself.

[Zen-cronic]

hey @Lms24 , anytime! I've been working on the graphqlClientIntegration for a while now, and i got somewhat familiar with the browser pkg. So, this fix seemed like a low-hanging fruit.
Appreciate that you digged into the mdn docs :)

[Lms24]

FYI, I'm waiting on #15164 before merging this to see if the integration tests need some adjustments afterwards.