[main] Update dependencies from microsoft/testfx

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/microsoft/testfx

• Subscription: 6b3b8571-4059-4db5-9b07-cd5e649ae2cc
• Build: 20260918.3 (332695)
• Date Produced: September 18, 2026 11:25:50 AM UTC
• Commit: 00b4e2a445a42b8768fdd706e7de778e582fb034
• Branch: main

• Dependency Updates:
  • From 2.5.0-preview.26467.6 to 2.5.0-preview.26468.3
    • Microsoft.Testing.Platform
  • From 4.5.0-preview.26467.6 to 4.5.0-preview.26468.3
    • MSTest

[microsoft-github-policy-service]

Auto-approve

[Copilot]

Copilot review overview

🟢 Approval recommended

The version and provenance updates are consistent with the described dependency build.

Review effort: Balanced
Findings: None

What changed in this PR

Updates MSTest and Microsoft.Testing.Platform preview dependencies to build 20260918.3.

Changes:

• Bumps MSTest to 4.5.0-preview.26468.3.
• Bumps Microsoft.Testing.Platform to 2.5.0-preview.26468.3.
• Synchronizes dependency metadata to commit 00b4e2a445.

File	Description
eng/​Versions.props	Updates package version properties.
eng/​Version.Details.xml	Updates dependency versions and source SHAs.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Final test-triage resolution — Azure Pipelines build 1603369

Analysis is final (completed build, evidenceIncomplete: false).

Failure: Dispose_FromANotificationHandler_DoesNotSelfWaitOnTheReadLoop (net462) in Microsoft.Testing.Platform.ServerMode.Client.Sources.UnitTests, on the Windows Release build leg. This was the only test failure/retry candidate across all matrix legs (74 candidates analyzed, only 1 failure signal). All other TFMs/OSes for the same test passed (net8.0 on Windows/Linux/macOS, net462 on Windows Debug).

Signature: Assert.IsLessThan(TimeSpan.FromSeconds(4), elapsed) failed — "Dispose from a notification handler took 5485 ms; it must not self-wait on the read loop" (upper bound 4s, actual ~5.48s).

Historical context (main branch, last 8 completed builds, partially incomplete — some artifact downloads failed/budget-exhausted, so absence elsewhere isn't proven): this exact test failed once before on an unrelated commit (build 1601991, net8.0 leg, ~8.0s actual vs 4s bound) and passed on all other sampled builds (6/8). This is a timing-sensitive assertion that has recurred intermittently despite three prior stabilization fixes (#10945, #10943, #11312, and the underlying #11074 "Fix flaky in-process disposal timing test").

Conclusion: This is a known-pattern environmental/timing flake in a fixed-bound timing assertion, not a defect introduced by this PR (an automated dependency-update PR). The specific occurrence here is a one-off (single leg, single run) and does not meet the durable-issue threshold (no proven fail-then-pass in this build, and the historical recurrence is against a different, unrelated commit rather than two builds of the same regression). No new issue is created; this failure alone should not block the PR beyond a normal retry.

Next step: if this recurs again, consider raising the timing bound further or moving to a deterministic rendezvous-based assertion instead of a wall-clock bound, consistent with the pattern in the closed fix history.

🤖 Automated content by GitHub Copilot. Generated by the Pipeline Test Triage workflow. · copilot · auto · 56.3 AIC · ⌖ 10.3 AIC · ⊞ 8.9K