Repository navigation
ref(develop): Clarify client report quantity for logs, metrics and spans - #19854
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Please update the IS YOUR CHANGE URGENT? section of the PR description:
This information helps the Docs team prioritize your review. |
|
The change adds quantity rules to four spec pages. The plan checks client errors and the TypeError share on the MDX catch-all route. An issue escalates when those errors rise. Page wording is not in telemetry. Services: PlanWhat changedFour SDK telemetry spec pages now state client-report quantity for discarded logs, metrics, and spans. The quantity is the number of contained items, not one per envelope. The pages are RiskBad MDX can fail the static build or break those four pages at runtime. A renderer error on the catch-all route can also affect sibling documentation pages. If the wording is wrong, SDK authors may record quantity 1 for batched envelopes. Intended effectThis is a documentation edit. Telemetry cannot show the new spec text. Regression watchA failed MDX render would show as client errors on the catch-all route that serves these pages. Pageload traces for the four routes returned no rows, so this watch uses error counts. Request volume is missing. Treat a sustained rise above the band as
If the error count rises, inspect events on Not observablePublished HTML of the four pages is not in Sentry, so the new wording has no telemetry signal. Pageload and navigation traces for those routes and for Get Slack DMs about this change: cursor.com/automations/rollouts |
Dropped span envelope items were recorded with a quantity of 1. Hybrid SDKs like sentry-dart send batched span items through sentry-java when span streaming is enabled, so read the count from the item_count header like we already do for logs and metrics. Refs [sentry-docs#19854](getsentry/sentry-docs#19854)
Prior to this commit, `ClientReportRecorder` didn't have any explicit logic for dealing with span envelopes because sentry-java didn't implement them. That meant that any span envelopes created by hybrid SDKs (in particular sentry-dart) and dropped by sentry-java would be shunted to the recorder's fallback branch and wrongly record a single dropped span per dropped envelope, rather than the actual number. This commit fixes that by adding the missing span envelope logic. Now sentry-java will report the actual span count, rather than 1. Refs [sentry-docs#19854](getsentry/sentry-docs#19854)
Prior to this commit, `ClientReportRecorder` didn't have any explicit logic for dealing with span envelopes because sentry-java didn't implement them. That meant that any span envelopes created by hybrid SDKs (in particular sentry-dart) and dropped by sentry-java would be shunted to the recorder's fallback branch and wrongly register a single dropped span per dropped envelope, rather than the actual number. This commit fixes that by adding the missing span envelope logic. Now sentry-java will report the actual span count, rather than 1. Refs [sentry-docs#19854](getsentry/sentry-docs#19854)
Prior to this commit, `ClientReportRecorder` didn't have any explicit logic for dealing with span envelopes because sentry-java didn't implement them. That meant that any span envelopes created by hybrid SDKs (in particular sentry-dart) and dropped by sentry-java would be shunted to the recorder's fallback branch and wrongly register a single dropped span per dropped envelope, rather than the actual number. This commit adds the missing span envelope logic. Now sentry-java will report the actual span count, rather than 1. Refs [sentry-docs#19854](getsentry/sentry-docs#19854)
Prior to this commit, `ClientReportRecorder` didn't have any explicit logic for dealing with span envelopes because sentry-java didn't implement them. That meant that any span envelopes created by hybrid SDKs (in particular sentry-dart) and dropped by sentry-java would be shunted to the recorder's fallback branch and wrongly register a single dropped span per dropped envelope, rather than the actual number. This commit adds the missing span envelope logic. Now sentry-java will report the actual span count, rather than 1. Refs [sentry-docs#19854](getsentry/sentry-docs#19854)
Prior to this commit, `ClientReportRecorder` didn't have any explicit logic for dealing with span envelopes because sentry-java didn't implement them. That meant that any span envelopes created by hybrid SDKs (in particular sentry-dart) and dropped by sentry-java would be shunted to the recorder's fallback branch and wrongly register a single dropped span per dropped envelope, rather than the actual number. This commit adds the missing span envelope logic. Now sentry-java will report the actual span count, rather than 1. Refs [sentry-docs#19854](getsentry/sentry-docs#19854) # Conflicts: # CHANGELOG.md
Clarifies
quantitiy