Many items in this project's issues are the same questions asked repeatedly: does this runtime propagate trace headers on its default HTTP client? Does it keep a span open for a streaming response? Does it report the right SDK name and runtime? Does double init do the same thing?
Each was found by reading one package and comparing to another. A table would have found them all at once, and would keep finding them.
Work item. Add a single matrix table to the repo (a test, or a generated doc) with one row per behavior and one column per runtime, covering at least:
| Behavior |
sdk.name and sdk.packages |
contexts.runtime.name / .version |
incoming server span: name, sentry.op, source |
incoming server span: continues an inbound sentry-trace |
| outgoing default HTTP client: child span created |
outgoing default HTTP client: sentry-trace + baggage sent |
| streaming response: span stays open until the body ends |
| streaming response: client cancel propagates upstream |
request body capture honors dataCollection.httpBodies |
ignoreStatusCodes drops the transaction |
| OPTIONS / HEAD produce no span |
double init() behavior |
| tracing-off: tracing integrations absent |
| unhandled error in the handler is captured and rethrown |
Fill it from the existing per-runtime integration tests where they already exist, and let the empty cells drive the backlog. This is the item with the highest long-term return; every other item in this document is one cell in it.
Prior art Four open issues ask for more test coverage, but none of them for a cross-runtime behavior matrix:
- #18635
- #20874
- #23610
- #22523
- #18635 similar, but it is about running existing suites against more frameworks, not about asking every runtime the same behavioral question.
Many items in this project's issues are the same questions asked repeatedly: does this runtime propagate trace headers on its default HTTP client? Does it keep a span open for a streaming response? Does it report the right SDK name and runtime? Does double init do the same thing?
Each was found by reading one package and comparing to another. A table would have found them all at once, and would keep finding them.
Work item. Add a single matrix table to the repo (a test, or a generated doc) with one row per behavior and one column per runtime, covering at least:
sdk.nameandsdk.packagescontexts.runtime.name/.versionsentry.op, sourcesentry-tracesentry-trace+baggagesentdataCollection.httpBodiesignoreStatusCodesdrops the transactioninit()behaviorFill it from the existing per-runtime integration tests where they already exist, and let the empty cells drive the backlog. This is the item with the highest long-term return; every other item in this document is one cell in it.
Prior art Four open issues ask for more test coverage, but none of them for a cross-runtime behavior matrix: