Repository navigation
deps: Bump xunit.v3 from 3.2.2 to 4.0.0 - #434
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Owner
ReviewWhat it does Good
Needs attention
Comments only — not approving or requesting changes. Generated by Claude Code |
Owner
|
Superseded by #442, which takes this bump along with the migration it forces. This isn't Dependabot's fault. xunit.v3 4.0.0 drops VSTest on the .NET 10 SDK, so the bump cannot build on its own: #442 switches the runner to Microsoft.Testing.Platform, ports both layers of the hang watchdog from #427, and drops Leaving this open until #442 lands. |
--- updated-dependencies: - dependency-name: xunit.v3 dependency-version: 4.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/nuget/tests/PlanViewer.Core.Tests/dev/xunit.v3-4.0.0
branch
from
August 21, 2026 09:14
ff46f5a to
bf1eaa7
Compare
erikdarlingdata
added a commit
that referenced
this pull request
Aug 21, 2026
…434) Dependabot #434 fails to build, and not because of anything it did wrong: Microsoft.Testing.Platform.MSBuild.targets(320,5): error : Testing with VSTest target is no longer supported by Microsoft.Testing.Platform on .NET 10 SDK and later. xunit.v3 4.0.0 drops VSTest on the .NET 10 SDK. There is no version of this bump that keeps the old runner, so it is migrate or stay on 3.2.2. #433 is the same family and passes only because bumping the VSTest adapter alone changes nothing. The opt-in is repo-level, not per-project, which the target names outright (_SupportsGlobalJsonTestRunner): global.json now selects the runner. Setting TestingPlatformDotnetTestSupport in the csproj alone does not do it, and I tried that first. xunit.runner.visualstudio is dropped because it IS the VSTest adapter and has no role here any more. That moots #433. The watchdog from 5f84116 needed porting, and this is the part worth reading. Both of its layers were VSTest-only: RunSettingsFilePath/TestSessionTimeout for bare local runs, and the blame-hang options in the three workflows. The local layer is now TestingPlatformCommandLineArguments carrying a 15m session timeout, same value and same no-flags-to-remember property; the workflows pass the hangdump options, which produce the same name-the-wedged-test artifact. I verified the local layer the way the original was verified, because a silently ignored property looks exactly like a working one: set it to 1ms temporarily and a bare `dotnet test` cancelled with 0 tests succeeded, then restored it. What the port does NOT recover, stated plainly because it would be easy to leave implied: neither MTP mechanism stops the GC-suspension livelock the original watchdog was written for. Measured against a genuinely wedged host on macOS ARM64, not assumed - it ran 2m55s at 107% CPU against a 90s hangdump timeout, and 8 minutes against a 60s session timeout, ignoring both. The reason is the same one 5f84116 gives for xUnit timeouts: the diagnostics the platform needs are served by the execution engine that is suspended. MTP does put the timeout in a separate controller process, which was the property that mattered, and it still cannot win. An ordinary hang, where the runtime is responsive, is killed fine. So this is not a regression against VSTest so much as both runners being equally powerless there, and I want to be careful not to claim more: I did not prove the OLD TestSessionTimeout could kill a livelocked host either. It was verified at 1ms on a healthy run, never against a real wedge. Filed separately. Tested: 279 passed, 0 failed, 2 skipped under the new runner (the whole suite except the Mcp/Repl classes, which wedge on macOS for reasons that predate this and are the subject of that separate issue). The CI flag form was run verbatim to confirm the options parse. dotnet build clean; the 9 warnings are the pre-existing MCP9005 obsolete-API uses in McpSmokeTests.cs. Two XML-comment '--' errors on the way in, exactly as 5f84116 warned. Noted in the comment so the next person does not rediscover it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
erikdarlingdata
added a commit
that referenced
this pull request
Aug 21, 2026
…434) (#442) Dependabot #434 fails to build, and not because of anything it did wrong: Microsoft.Testing.Platform.MSBuild.targets(320,5): error : Testing with VSTest target is no longer supported by Microsoft.Testing.Platform on .NET 10 SDK and later. xunit.v3 4.0.0 drops VSTest on the .NET 10 SDK. There is no version of this bump that keeps the old runner, so it is migrate or stay on 3.2.2. #433 is the same family and passes only because bumping the VSTest adapter alone changes nothing. The opt-in is repo-level, not per-project, which the target names outright (_SupportsGlobalJsonTestRunner): global.json now selects the runner. Setting TestingPlatformDotnetTestSupport in the csproj alone does not do it, and I tried that first. xunit.runner.visualstudio is dropped because it IS the VSTest adapter and has no role here any more. That moots #433. The watchdog from 5f84116 needed porting, and this is the part worth reading. Both of its layers were VSTest-only: RunSettingsFilePath/TestSessionTimeout for bare local runs, and the blame-hang options in the three workflows. The local layer is now TestingPlatformCommandLineArguments carrying a 15m session timeout, same value and same no-flags-to-remember property; the workflows pass the hangdump options, which produce the same name-the-wedged-test artifact. I verified the local layer the way the original was verified, because a silently ignored property looks exactly like a working one: set it to 1ms temporarily and a bare `dotnet test` cancelled with 0 tests succeeded, then restored it. What the port does NOT recover, stated plainly because it would be easy to leave implied: neither MTP mechanism stops the GC-suspension livelock the original watchdog was written for. Measured against a genuinely wedged host on macOS ARM64, not assumed - it ran 2m55s at 107% CPU against a 90s hangdump timeout, and 8 minutes against a 60s session timeout, ignoring both. The reason is the same one 5f84116 gives for xUnit timeouts: the diagnostics the platform needs are served by the execution engine that is suspended. MTP does put the timeout in a separate controller process, which was the property that mattered, and it still cannot win. An ordinary hang, where the runtime is responsive, is killed fine. So this is not a regression against VSTest so much as both runners being equally powerless there, and I want to be careful not to claim more: I did not prove the OLD TestSessionTimeout could kill a livelocked host either. It was verified at 1ms on a healthy run, never against a real wedge. Filed separately. Tested: 279 passed, 0 failed, 2 skipped under the new runner (the whole suite except the Mcp/Repl classes, which wedge on macOS for reasons that predate this and are the subject of that separate issue). The CI flag form was run verbatim to confirm the options parse. dotnet build clean; the 9 warnings are the pre-existing MCP9005 obsolete-API uses in McpSmokeTests.cs. Two XML-comment '--' errors on the way in, exactly as 5f84116 warned. Noted in the comment so the next person does not rediscover it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Owner
|
Landed via #442, which took this bump along with the Microsoft.Testing.Platform migration it forces. |
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/nuget/tests/PlanViewer.Core.Tests/dev/xunit.v3-4.0.0
branch
August 21, 2026 10:16
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
1 participant
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.
Updated xunit.v3 from 3.2.2 to 4.0.0.
Release notes
Sourced from xunit.v3's releases.
No release notes found for this version range.
Commits viewable in compare view.