Repository navigation
fix(test): bound process-output drains in test helpers - #117
Merged
Merged
Conversation
Six test helpers ran pack-core.sh or dotnet build/pack/restore with redirected output and then awaited ReadToEndAsync with no timeout. A reusable MSBuild worker node inherits the pipe and outlives the script, so EOF never arrived until the node idled out (~15 min). This hung the three InitCommandTests, and Core's ComposedCoreFeedFixture has the same shape. All six now call one shared test/Shared/ProcessRunner.cs, linked into Dmon.Core.Tests and Dmon.Terminal.Tests. It sets MSBUILDDISABLENODEREUSE=1 on every child and bounds the post-exit drain with a grace, returning truncated output rather than blocking when a descendant still holds the pipe. Each measure is sufficient alone; both were forced from zero build nodes with node reuse on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015CJu5CxqY5B6o3GfMVAfsu
Record the fix, the forcing runs in both directions, and a correction: OutputDataReceived-mode reads do not escape the hang, because WaitForExitAsync waits for EOF on them. Note that production's BuildFileBasedProgramAsync has the same shape but did not reproduce, and that the suspected Core-hang mechanism is now closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015CJu5CxqY5B6o3GfMVAfsu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves the
tech-debt/terminal-tests-hang.mditem.Problem
Six test helpers (Terminal's
InitFeedFixtureandInitCommandTests; Core'sComposedCoreFeedFixture,CompositionRootTests,ToolPackTestsandVersionRangeRestoreTests) ranpack-core.shordotnet build/pack/restorewith redirected output. They waited for the process to exit, then awaitedReadToEndAsyncwith no timeout. A reusable MSBuild worker node inherits the pipe and outlives the script, so EOF never arrived until the node idled out (~15 min).Fix
One shared helper,
test/Shared/ProcessRunner.cs, compiled into both test projects as a linked file:MSBUILDDISABLENODEREUSE=1on every child process.It deliberately does not use
BeginOutputReadLine:WaitForExitAsyncwaits for EOF on streams read that way, which would reproduce the hang.ProcessRunnerTestsproves measure 2 in isolation.Verification
All runs started from zero MSBuild nodes, with node reuse on, using
--filter InitCommandTests:main(before): hung, aborted at the 2 min hang timeoutnodeReuse:truenode, so measure 2 alone survived the hang conditionTwo full
dotnet test Everything.slnxruns without the workaround variable: every assembly passed, about 70 s each.A production site,
CoreProcessManager.BuildFileBasedProgramAsync, has the same shape. It did not reproduce (a single-project build appears not to start a worker node) and is left alone, as recorded in the note.🤖 Generated with Claude Code
https://claude.ai/code/session_015CJu5CxqY5B6o3GfMVAfsu