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
{{ message }}
Repository navigation
System.Transactions.Tests.OleTxTests.Recovery fails with timeout #126304
{
"ErrorMessage": ["[Long Running Test] 'System.Transactions.Tests.OleTxTests.Recovery'" ,"'System.Transactions.Local.Tests' END OF WORK ITEM LOG: Command timed out, and was killed"],
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}
Known issue validation
Build: 🔎https://dev.azure.com/dnceng-public/public/_build/results?buildId=1356516 Error message validated:[[Long Running Test] 'System.Transactions.Tests.OleTxTests.Recovery' 'System.Transactions.Local.Tests' END OF WORK ITEM LOG: Command timed out, and was killed] Result validation: ✅ Known issue matched with the provided build. Validation performed at: 3/30/2026 10:49:33 AM UTC
2× unknown — internal builds 2927142, 2910060 (empty run name)
19× unknown — older runs, both build and test run APIs return 404
Since the test runs just as much as far as I can see on release runtimes/non stress, this seemed statistically significant enough that disabling for non release/stress and/or adding a longer timeout somewhere might at least reduce the failure rate. .. thoughts?
(Assuming (IDK) that "regular release runtime" runs are 50% of all runs, it seems statistically significant that 6 out of 7 of the failures we know were in those)
Activity
dotnet-policy-service commentedon Mar 30, 2026
Tagging subscribers to this area: @SamMonoRT, @dotnet/efteam
See info in area-owners.md if you want to be subscribed.
MihuBot commentedon Mar 30, 2026
I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):
JulieLeeMSFT commentedon Mar 31, 2026
Summary:
System.Transactions.Tests.OleTxTests.Recovery times out (>28 min) under fullpgo stress mode on Windows x64.
Failed in (1):
Console Log: Console Log
Failed tests:
JulieLeeMSFT commentedon Mar 31, 2026
cc @danmoseley.
danmoseley commentedon Apr 8, 2026
#125813 didn't help or at least wasn't sufficient.
danmoseley commentedon Apr 8, 2026
Let's just skip on slow runtimes.
jkotas commentedon Apr 8, 2026
I do not think it is going to help. Based on the symptoms, it is intermittent hang in the native Windows component that this test calls into.
Disable OleTxTests.Recovery under JIT stress configurations
danmoseley commentedon Apr 8, 2026
Most likely, but I was looking at the history (including the linked issue) -- copilot data, not manually confirmed:
Since the test runs just as much as far as I can see on release runtimes/non stress, this seemed statistically significant enough that disabling for non release/stress and/or adding a longer timeout somewhere might at least reduce the failure rate. .. thoughts?
(Assuming (IDK) that "regular release runtime" runs are 50% of all runs, it seems statistically significant that 6 out of 7 of the failures we know were in those)
It's not super hitty but these add up and cost.
danmoseley commentedon Apr 9, 2026
As noted in PR we are going to try to get a dump
jakobbotsch commentedon Jun 9, 2026
This failed in https://dev.azure.com/dnceng-public/public/_build/results?buildId=1455642&view=logs&jobId=51e4640a-c078-5be6-cc1b-f971e75d762f&j=51e4640a-c078-5be6-cc1b-f971e75d762f&t=325dd1cc-a862-54bb-9def-23eb1f229981.
Console log: https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-129157-merge-63cc14302d474974a0/System.Transactions.Local.Tests/1/console.3bb4cf50.log
SamMonoRT commentedon Jul 14, 2026
This is non-deterministic, low priority and moving to Future milestone.
JulieLeeMSFT commentedon Jul 29, 2026
This seems the same failure: #131448.
jeffschwMSFT commentedon Aug 13, 2026
removing blocking-clean-ci as it has not failed in 30 days
24-Hour Hit Count 7-Day Hit Count 1-Month Count
0 0 0