Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1347187
Leg Name: Libraries Test Run release coreclr osx arm64 Debug, Libraries Test Run checked coreclr osx arm64 Debug
Error Message
{
"ErrorPattern": "NumberFormatInfoMiscTests\\.TestNativeDigits.*(?:failed|FAIL)",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Description
TestNativeDigits(cultureName: "ur-IN") fails deterministically on macOS (Apple platforms) after the xunit v3 assert upgrade (Microsoft.DotNet.XUnitAssert 2.9.3 → 3.2.2).
Root cause: The test was not actually executing under xunit v2 — as Andy Gocke noted in commit ffdb8ad ("Fix TestNativeDigits, which it looks like was not running properly"). The xunit v3 upgrade made ConditionalTheory + MemberData work correctly, causing the test to actually run for the first time.
On Apple platforms, ICU returns ASCII/Latin digits ("0", "1", ..., "9") for CultureInfo.GetCultureInfo("ur-IN").NumberFormat.NativeDigits, not the Extended Arabic-Indic digits (U+06F0–U+06F9) that the test expects. This is an Apple ICU locale data divergence from upstream CLDR (which specifies arabext for ur-IN). This has likely always been the case on Apple platforms but was never observed because the test never ran.
Andy caught and fixed the same pattern for ccp-Cakm-BD (wrong digit block entirely) but missed ur-IN.
Fix PR: #125934
Failure output:
System.Globalization.Tests.NumberFormatInfoMiscTests.TestNativeDigits(cultureName: "ur-IN", nativeDigits: ["۰", "۱", "۲", "۳", "۴", ···]) [FAIL]
Assert.Equal() Failure: Collections differ
Expected: ["۰", "۱", "۲", "۳", "۴", "۵", "۶", "۷", "۸", "۹"]
Actual: ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"]
Helix log: https://helix.dot.net/api/2019-06-17/jobs/a3cadb27-b01d-4efb-9c80-75c87054ce8a/workitems/System.Globalization.Tests/console
Environment: OSX.26.Arm64.Open (macOS 26.0.1), both checked and release coreclr legs affected.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1347187
Error message validated: [System\.Globalization\.Tests\.NumberFormatInfoMiscTests\.TestNativeDigits\(cultureName: "ur-IN", nativeDigits: \["\u06F0"]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/22/2026 9:43:18 PM UTC
Report
Summary
| 24-Hour Hit Count |
7-Day Hit Count |
1-Month Count |
| 1 |
1 |
1 |
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1347187
Error message validated: [NumberFormatInfoMiscTests\.TestNativeDigits.*(?:failed|FAIL)]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/23/2026 4:27:01 AM UTC
Report
Summary
| 24-Hour Hit Count |
7-Day Hit Count |
1-Month Count |
| 1 |
1 |
1 |
Report
Summary
| 24-Hour Hit Count |
7-Day Hit Count |
1-Month Count |
| 2 |
12 |
43 |
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1347187
Leg Name: Libraries Test Run release coreclr osx arm64 Debug, Libraries Test Run checked coreclr osx arm64 Debug
Error Message
{ "ErrorPattern": "NumberFormatInfoMiscTests\\.TestNativeDigits.*(?:failed|FAIL)", "BuildRetry": false, "ExcludeConsoleLog": false }Description
TestNativeDigits(cultureName: "ur-IN")fails deterministically on macOS (Apple platforms) after the xunit v3 assert upgrade (Microsoft.DotNet.XUnitAssert2.9.3 → 3.2.2).Root cause: The test was not actually executing under xunit v2 — as Andy Gocke noted in commit ffdb8ad ("Fix TestNativeDigits, which it looks like was not running properly"). The xunit v3 upgrade made
ConditionalTheory+MemberDatawork correctly, causing the test to actually run for the first time.On Apple platforms, ICU returns ASCII/Latin digits (
"0","1", ...,"9") forCultureInfo.GetCultureInfo("ur-IN").NumberFormat.NativeDigits, not the Extended Arabic-Indic digits (U+06F0–U+06F9) that the test expects. This is an Apple ICU locale data divergence from upstream CLDR (which specifiesarabextfor ur-IN). This has likely always been the case on Apple platforms but was never observed because the test never ran.Andy caught and fixed the same pattern for
ccp-Cakm-BD(wrong digit block entirely) but missedur-IN.Fix PR: #125934
Failure output:
Helix log: https://helix.dot.net/api/2019-06-17/jobs/a3cadb27-b01d-4efb-9c80-75c87054ce8a/workitems/System.Globalization.Tests/console
Environment: OSX.26.Arm64.Open (macOS 26.0.1), both checked and release coreclr legs affected.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1347187
Error message validated:
[System\.Globalization\.Tests\.NumberFormatInfoMiscTests\.TestNativeDigits\(cultureName: "ur-IN", nativeDigits: \["\u06F0"]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/22/2026 9:43:18 PM UTC
Report
Summary
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1347187
Error message validated:
[NumberFormatInfoMiscTests\.TestNativeDigits.*(?:failed|FAIL)]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/23/2026 4:27:01 AM UTC
Report
Summary
Report
Summary