Description
Sentry.AspNetCore.Tests.WebIntegrationTests.Versioning fails intermittently on net11.0 on the version7 branch, and it has failed on a different platform almost every time — so it is timing-dependent rather than platform-specific.
Observed on PRs targeting version7 (each needed a job re-run):
| PR |
commit |
platform |
| #5573 |
0aada878 |
linux-musl-arm64 |
| #5573 |
3307c301 |
linux-musl-x64 |
| #5573 |
9d271126 |
linux-musl-arm64 |
| #5585 |
f76ac32f |
linux-musl-x64 |
Cause
The verified snapshot ends with the structured-log envelope item:
{
Source: {
Length: 7
}
}
Source is the JsonSerializable's source object — a Sentry.Protocol.StructuredLog — and Verify renders its Length property, which is the number of SentryLog items in the batch. So the snapshot asserts an exact count of the framework logs (Microsoft.AspNetCore.*) captured while serving one request.
Failing runs produce Length: 6. The received file is otherwise byte-identical; the only diff is the count:
96c96
< Length: 7
---
> Length: 6
The count became load-bearing when #5504 made logs always enabled: the test now depends on every framework log for that request reaching the batch before server.Dispose() triggers the flush. One arriving late gives 6.
Suggested fix
Stop asserting the count while keeping the rest of the envelope. Sentry.Testing and Sentry.AspNetCore.Tests both have InternalsVisibleTo, so it can be scrubbed by type in IgnoreStandardSentryMembers (test/Sentry.Testing/VerifyExtensions.cs):
.IgnoreMembers<StructuredLog>(_ => _.Length)
Only one committed snapshot contains a Length: line, so the blast radius is this test alone.
A stronger alternative is to make the capture deterministic (assert on log content, or stop the framework logs racing the flush), but that is a larger change and the count is not what this test is about — it verifies API-versioning data on the transaction.
Impact
Until it is fixed, every PR targeting version7 needs a re-run of one .NET job roughly half the time. It is unrelated to the changes in those PRs.
Description
Sentry.AspNetCore.Tests.WebIntegrationTests.Versioningfails intermittently on net11.0 on theversion7branch, and it has failed on a different platform almost every time — so it is timing-dependent rather than platform-specific.Observed on PRs targeting
version7(each needed a job re-run):0aada8783307c3019d271126f76ac32fCause
The verified snapshot ends with the structured-log envelope item:
Sourceis theJsonSerializable's source object — aSentry.Protocol.StructuredLog— and Verify renders itsLengthproperty, which is the number ofSentryLogitems in the batch. So the snapshot asserts an exact count of the framework logs (Microsoft.AspNetCore.*) captured while serving one request.Failing runs produce
Length: 6. The received file is otherwise byte-identical; the only diff is the count:The count became load-bearing when #5504 made logs always enabled: the test now depends on every framework log for that request reaching the batch before
server.Dispose()triggers the flush. One arriving late gives 6.Suggested fix
Stop asserting the count while keeping the rest of the envelope.
Sentry.TestingandSentry.AspNetCore.Testsboth haveInternalsVisibleTo, so it can be scrubbed by type inIgnoreStandardSentryMembers(test/Sentry.Testing/VerifyExtensions.cs):Only one committed snapshot contains a
Length:line, so the blast radius is this test alone.A stronger alternative is to make the capture deterministic (assert on log content, or stop the framework logs racing the flush), but that is a larger change and the count is not what this test is about — it verifies API-versioning data on the transaction.
Impact
Until it is fixed, every PR targeting
version7needs a re-run of one.NETjob roughly half the time. It is unrelated to the changes in those PRs.