feat(metrics): initialise MULTIPLEXED_METRIC_ROUTING_KEY for routing#19096
feat(metrics): initialise MULTIPLEXED_METRIC_ROUTING_KEY for routing#19096harshit078 wants to merge 28 commits intogetsentry:developfrom
Conversation
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
Hi @chargome, the PR is ready to review. Thanks ! |
chargome
left a comment
chargome
left a comment
There was a problem hiding this comment.
Nice, thanks for opening the PR! I left some comments. Also, we definitely want to test this behaviour somehow in a browser integration test.
| const container = Array.isArray(item) ? (item[1] as SerializedMetricContainer) : undefined; | ||
| const containerItems = container?.items; | ||
| if (containerItems) { | ||
| metric = containerItems[0]; |
There was a problem hiding this comment.
Wouldn't this mean we always just pull the first metric?
There was a problem hiding this comment.
yes it would mean we pull the first metric. What I'm thinking now after your comment is that I can add a logic which will check if all metrics and route to same or multiple destinations. Whats your opinion ?
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
|
Unrelated to this PR, I sent you an email @harshit078. Let me know if you have any questions about it. |
|
Hey @andreiborza , I got the email sent by you and I just replied back to it ;) |
chargome
left a comment
chargome
left a comment
There was a problem hiding this comment.
Thinking about this again I think we're facing a fundamental design issue here. We always batch metrics into one envelope for sending them. So whatever routing destination the first metric in the envelope has will overrule the others. Same for applying the release as attribute. We would therefore need to split up the envelopes per routing destination before sending them. I'm currently leaning against having that much logic for this feature and this increasing bundle size unless we get a clear signal from the users that we should support this. We might even want to partition the buffer onto DSNs.
Summed up, this approach is too brittle atm. Sorry for the back and forth on this one but I will close the PR and resolve this internally once needed!
| getSpanStatusFromHttpCode, | ||
| setHttpStatus, | ||
| makeMultiplexedTransport, | ||
| MULTIPLEXED_TRANSPORT_EXTRA_KEY, |
There was a problem hiding this comment.
This is still a breaking change
3 participants
Before submitting a pull request, please take a look at our
Contributing guidelines and verify:
yarn lint) & (yarn test).Closes #18913
What changed
metricsMetricRoutingInfowith dsn and release as its fieldMetricOptionsand enabledcaptureMetricto inject routing info into attributesInternalCaptureMetricOptions_stripRoutingAttributesfunction which removes routing info before sending to sentry