Skip to content

test: verify automatic flush on exit without Stop-Sentry#138

Draft
jamescrosswell wants to merge 3 commits into
mainfrom
test/issue-38-flush-on-exit
Draft

test: verify automatic flush on exit without Stop-Sentry#138
jamescrosswell wants to merge 3 commits into
mainfrom
test/issue-38-flush-on-exit

Conversation

@jamescrosswell
Copy link
Copy Markdown
Collaborator

Summary

Adds a regression test for automatic flush on process exit. After #85 removed the workaround that disabled the .NET SDK's AppDomain.ProcessExit flush hook (the workaround existed because that hook used to hang/crash — getsentry/sentry-dotnet#3141, fixed in getsentry/sentry-dotnet#4323), a script should no longer need to call Stop-Sentry for events to be delivered.

The test launches a child process that:

  1. Starts Sentry with a file-writing transport,
  2. captures a message, and
  3. exits without calling Stop-Sentry.

The parent then asserts the child:

  • exited within a timeout (i.e. did not hang on exit), and
  • exited cleanly (exit code 0), and
  • still delivered the captured event.

A FileTransport (added to tests/utils.ps1) serializes envelopes to disk so delivery is observable from the parent after the child exits, avoiding networking/open ports in CI.

The main goal is to confirm this holds on the Windows CI matrices (Windows PowerShell 5.1 / net462 — the platform the synchronous transport design targets), which we couldn't validate locally.

Closes #38

#skip-changelog

Add a regression test for #38 that runs a child process which starts Sentry,
captures a message, and exits WITHOUT calling Stop-Sentry. It asserts the
process exits cleanly within a timeout (no hang, as in sentry-dotnet#3141) and
that the captured event is still delivered.

A file-writing transport (FileTransport in utils.ps1) is used so delivery can be
observed from the parent after the child exits, without networking/ports in CI.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Comment thread tests/exit-flush.tests.ps1 Fixed
jamescrosswell and others added 2 commits May 29, 2026 12:03
When powershell.exe (Windows PowerShell) is spawned from a pwsh host, the
inherited PSModulePath points only at PowerShell Core's module directories,
preventing autoload of Microsoft.PowerShell.Utility (Import-PowerShellDataFile),
which the module's psm1 uses during import. Reset to the machine default under
Desktop edition so built-in modules are discoverable.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Windows PowerShell 5.1 does not reliably populate .ExitCode on the object
returned by `Start-Process -PassThru` after WaitForExit(timeout). Start the
child via System.Diagnostics.Process instead, reading stdout/stderr async to
avoid pipe-buffer deadlocks, so the exit code is available on both editions.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
try {
$exited = $proc.WaitForExit($TimeoutSeconds * 1000)
if (-not $exited) {
try { $proc.Kill() } catch {}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Automatic flush on exit

2 participants