Skip to content

[vs18.7] Update dependencies from dotnet/arcade#13863

Merged
OvesN merged 2 commits into
vs18.7from
darc-vs18.7-3bb050b6-7e1c-45cb-8f14-614b4469ece6
May 25, 2026
Merged

[vs18.7] Update dependencies from dotnet/arcade#13863
OvesN merged 2 commits into
vs18.7from
darc-vs18.7-3bb050b6-7e1c-45cb-8f14-614b4469ece6

Conversation

@dotnet-maestro
Copy link
Copy Markdown
Contributor

This pull request updates the following dependencies

From https://github.com/dotnet/arcade

…519.10

On relative base path root
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XUnitV3Extensions From Version 10.0.0-beta.26257.4 -> To Version 10.0.0-beta.26269.10
@dotnet-maestro dotnet-maestro Bot requested a review from a team as a code owner May 25, 2026 05:05
@OvesN OvesN merged commit 1b88a49 into vs18.7 May 25, 2026
11 checks passed
@OvesN OvesN deleted the darc-vs18.7-3bb050b6-7e1c-45cb-8f14-614b4469ece6 branch May 25, 2026 14:22
jankratochvilcz added a commit that referenced this pull request May 25, 2026
…13864)

Deterministic rewrite for the `ToolTaskThatTimeoutAndRetry` flake
tracked in #13667.

## Background

After the bump in #13830 (slowDelay 20s, timeout 5s) the test still
flaked: a 4-day telemetry harvest of dnceng-public PR CI surfaced 2
failures on a no-code Arcade dependency-bump PR (#13863), proving the
bumped budget is the floor, not a comfortable ceiling.

## Root cause

The test set `task.Timeout` **once before the loop** and shared it
across every attempt. On the `(3, true)` case the follow-up attempts run
`ping -n 2` (~1-2s) against the shared 5s budget, leaving only 3-4s of
headroom for CI cold-start overhead. The success-path attempts have **no
semantic reason** to be wall-clock-bounded -- the test asserts they
succeed regardless of how long the underlying ping/sleep takes. They
were only coupled to the timing-out attempt because both used the same
`Timeout` field.

## Fix

1. **Set `task.Timeout` per attempt.** Only the attempt expected to time
out gets a finite 2s budget; every other attempt uses
`Timeout.Infinite`. Removes all wall-clock dependency from the success
path.
2. **Tighten `slowDelay` from 20s to 10s.** With Timeout=2s, ping ~10s
vs timeout 2s gives 5x headroom -- the tool cannot finish before the
timeout fires on any agent. Also halves test wall clock (~4-6s vs
~7-9s).

## Telemetry for post-merge health checks

The test emits a stable-prefix line per attempt so future flake-trend
analysis can grep it out of test stdout attachments:

\\\
[TTTAR-TELEMETRY] attempt=1/3 role=timeoutAttempt expectedSuccess=False
actualSuccess=False exitCode=-1 elapsedMs=2034 configuredTimeoutMs=2000
slowDelayMs=10000 fastDelayMs=100
[TTTAR-TELEMETRY] attempt=2/3 role=successAttempt expectedSuccess=True
actualSuccess=True exitCode=0 elapsedMs=1521 configuredTimeoutMs=-1
slowDelayMs=10000 fastDelayMs=100
\\\

**Health-check recipe** (after the change has soaked for a few days):
1. `[TTTAR-TELEMETRY] ... actualSuccess=False expectedSuccess=True`
anywhere in passing-build stdout = flake re-emerged on the success path;
investigate immediately.
2. For `role=timeoutAttempt`, `elapsedMs` should be in roughly `[1900,
3000]` ms (timeout fires plus process-kill overhead). A consistent drift
to the high end signals process-termination regressions.
3. For `role=successAttempt`, `elapsedMs` is uncapped by design; collect
the distribution to know what budget margin we have if we ever want to
re-introduce a Timeout on success.

## Verification

5 consecutive local runs × 6 inline cases = **30/30 passing** on
`net10.0|x64` and `net48|x86`.

Opening as draft -- happy to iterate on shape.
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.

3 participants