Description
The msbuild integration test (integration-test/msbuild.Tests.ps1, "builds without warnings and is able to capture a message") intermittently fails on Windows in its net9.0 context. The app enqueues the envelope, then the flush at process exit times out, so the mock server never receives it and the assertion fails:
Debug: Enqueuing envelope 59bc6545190747e9ab304f3f5e62edda
Info: Envelope queued up: '59bc6545190747e9ab304f3f5e62edda'
Info: AppDomain process exited: Disposing SDK.
Info: Disposing the Hub.
Debug: Timeout when trying to flush queue.
Expected string '"message":"Hello from MSBuild app"' to match any element in collection @().
at $result.Envelopes() | Should -AnyElementMatch …, integration-test/msbuild.Tests.ps1:101
Occurrences
Both on Windows, both in the net9.0 context, both showing Timeout when trying to flush queue:
The net5.0 and net8.0 contexts passed in the same runs.
Cause
The app the test generates never flushes explicitly:
SentrySdk.Init(options =>
{
options.Dsn = args[0];
options.Debug = true;
});
SentrySdk.CaptureMessage($"Hello from MSBuild app");Delivery therefore depends entirely on the AppDomain.ProcessExit handler disposing the SDK, which flushes with SentryOptions.ShutdownTimeout — 2 seconds by default. On a loaded Windows runner, the first (and only) envelope has to pay for connection setup to the local mock server, gzip, and debug-image processing inside that window. When it doesn't make it, the SDK logs the timeout, drops the envelope, and the assertion fails.
So this is a deadline the test inherits by accident rather than a product bug: 2 seconds is the documented default, and the test simply assumes a cold-start send fits inside it.
Suggested fix
Make delivery deterministic in the generated app rather than raising CI timeouts — either
options.ShutdownTimeout = TimeSpan.FromSeconds(30);
or an explicit SentrySdk.Flush(TimeSpan.FromSeconds(30)) after the capture. Worth checking the other Pester integration tests for the same assumption while we're there.
Not related to the v7 logging work
Seen on two different PRs in the #5245 stack, but the app under test references the packed core SDK only — no Serilog or NLog involvement — and the same test passes on the other target frameworks in the same runs.
Description
The
msbuildintegration test (integration-test/msbuild.Tests.ps1, "builds without warnings and is able to capture a message") intermittently fails on Windows in its net9.0 context. The app enqueues the envelope, then the flush at process exit times out, so the mock server never receives it and the assertion fails:Occurrences
Both on Windows, both in the net9.0 context, both showing
Timeout when trying to flush queue:0aada878.NET (win-x64)→ step 27 "Integration test"f76ac32fMSBuild→ step 8 "Test MSBuild"The net5.0 and net8.0 contexts passed in the same runs.
Cause
The app the test generates never flushes explicitly:
Delivery therefore depends entirely on the
AppDomain.ProcessExithandler disposing the SDK, which flushes withSentryOptions.ShutdownTimeout— 2 seconds by default. On a loaded Windows runner, the first (and only) envelope has to pay for connection setup to the local mock server, gzip, and debug-image processing inside that window. When it doesn't make it, the SDK logs the timeout, drops the envelope, and the assertion fails.So this is a deadline the test inherits by accident rather than a product bug: 2 seconds is the documented default, and the test simply assumes a cold-start send fits inside it.
Suggested fix
Make delivery deterministic in the generated app rather than raising CI timeouts — either
or an explicit
SentrySdk.Flush(TimeSpan.FromSeconds(30))after the capture. Worth checking the other Pester integration tests for the same assumption while we're there.Not related to the v7 logging work
Seen on two different PRs in the #5245 stack, but the app under test references the packed core SDK only — no Serilog or NLog involvement — and the same test passes on the other target frameworks in the same runs.