Repository navigation
iOS tests failing with OSError: [Errno 28] No space left on device #6473
Description
Build
Build leg reported
iOS.Device.Aot.Test.WorkItemExecution
Pull Request
Known issue core information
Fill out the known issue JSON section by following the step by step documentation on how to create a known issue
{
"ErrorMessage" : "OSError: [Errno 28] No space left on device",
"BuildRetry": false,
"ErrorPattern": "",
"ExcludeConsoleLog": false
}@dotnet/dnceng
Release Note Category
- Feature changes/additions
- Bug fixes
- Internal Infrastructure Improvements
Release Note Description
Additional information about the issue reported
No response
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1337140
Error message validated: [OSError: [Errno 28] No space left on device]
Result validation: ❌ Known issue did not match with the provided build.
Validation performed at: 3/16/2026 4:54:41 PM UTC
Report
| Build | Repository | Test | Pull Request |
|---|---|---|---|
| 1624231 | dotnet/runtime | Microsoft.Extensions.FileProviders.Physical.Tests.WorkItemExecution |
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 1 |
Activity
liuminsheng3 commentedon Jun 16, 2026
Since this known issue is recurring across many
WorkItemExecutionlegs, I would treat it as a per-work-item disk budget problem rather than only matching the finalOSError: [Errno 28]line.The useful split is to capture sizes before the iOS work item starts and again on failure, then separate:
For iOS/macOS legs I would also bucket DerivedData, simulator data, NuGet/package caches, test payloads, crash dumps, and any copied app bundles separately. Those have different cleanup risk; deleting simulator runtimes or shared tool state is much riskier than rotating per-work-item temp/output.
I made a read-only macOS CI storage scan/checklist for exactly this style of runner evidence collection. It does not delete anything; it just produces the before/after artifact needed to decide safe vs review-first cleanup:
https://site-iota-ebon-80.vercel.app/ci-macos-storage-scan.html?utm_source=github&utm_medium=issue-comment&utm_campaign=ci-macos-storage&utm_term=dotnet-ios-tests-errno28&utm_content=dotnet-dnceng-6473
The important signal for this issue is whether the repeated hits are dominated by one growing work item payload, shared Xcode/simulator state, or temp output that is not being removed between attempts.