You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pipeline: runtime-coreclr jitstress (definition 109, optional rolling stress pipeline), branch main. The failure reproduces across multiple stress-mode legs and persists into follow-up build 1494001.
Error Details
Under JIT stress, Async2ManagedThreadId.TestThreadIdReflectsResumptionThread fails its Assert.Equal check: the managed thread id observed after the async resumption does not match the expected value (the concrete expected/actual thread-id numbers vary from run to run, so they are excluded from the match signature):
Running test: _regression_managed_thread_id::Async2ManagedThreadId.TestThreadIdReflectsResumptionThread()
Xunit.Sdk.EqualException: Assert.Equal() Failure: Values differ
Expected: 1
Actual: 11
at Xunit.Assert.Equal[T](T expected, T actual, IEqualityComparer`1 comparer)
at Async2ManagedThreadId.TestThreadIdReflectsResumptionThreadAsync()
Failed test: _regression_managed_thread_id::Async2ManagedThreadId.TestThreadIdReflectsResumptionThread()
Present in source build 1492736 and confirmed still failing across multiple legs of follow-up build 1494001. The signature is scoped to the async-resumption stack frame, which appears only on failure.
Duplicate search
Searched open and closed Known Build Error issues for Async2ManagedThreadId, TestThreadIdReflectsResumptionThread, and the assertion text: no existing KBE.
Filed by the CI outer-loop failure scanner (detection only). Mitigation — a fix PR or JIT-owner hand-off — is handled by the companion ci-failure-fix workflow, which walks open [ci-scan] KBEs.
Note
This issue was generated with the assistance of GitHub Copilot (AI). Signatures and build references were verified against public AzDO / Helix logs.
Note
🔒 Integrity filter blocked 5 items
The following items were blocked because they don't meet the GitHub integrity level.
#114222search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#127541search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#117370search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#50848search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#19341search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower min-integrity in your GitHub frontmatter:
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1492736
Build error leg or test failing: coreclr Pri1 Runtime Tests Run linux x64 checked - _regression_managed_thread_id::Async2ManagedThreadId.TestThreadIdReflectsResumptionThread
Pipeline:
runtime-coreclr jitstress(definition 109, optional rolling stress pipeline), branchmain. The failure reproduces across multiple stress-mode legs and persists into follow-up build 1494001.Error Details
Under JIT stress,
Async2ManagedThreadId.TestThreadIdReflectsResumptionThreadfails itsAssert.Equalcheck: the managed thread id observed after the async resumption does not match the expected value (the concrete expected/actual thread-id numbers vary from run to run, so they are excluded from the match signature):Error Message
{ "ErrorMessage": [ "Assert.Equal() Failure: Values differ", "at Async2ManagedThreadId.TestThreadIdReflectsResumptionThreadAsync()" ], "ErrorPattern": "", "BuildRetry": false, "ExcludeConsoleLog": false }First build it occurred
Present in source build 1492736 and confirmed still failing across multiple legs of follow-up build 1494001. The signature is scoped to the async-resumption stack frame, which appears only on failure.
Duplicate search
Searched open and closed
Known Build Errorissues forAsync2ManagedThreadId,TestThreadIdReflectsResumptionThread, and the assertion text: no existing KBE.Filed by the CI outer-loop failure scanner (detection only). Mitigation — a fix PR or JIT-owner hand-off — is handled by the companion
ci-failure-fixworkflow, which walks open[ci-scan]KBEs.Note
This issue was generated with the assistance of GitHub Copilot (AI). Signatures and build references were verified against public AzDO / Helix logs.
Note
🔒 Integrity filter blocked 5 items
The following items were blocked because they don't meet the GitHub integrity level.
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".To allow these resources, lower
min-integrityin your GitHub frontmatter:Report
Summary