[CI][macOS] NSPasteboard FileUrl write returns false before metadata detection #27141

Apple platform

macOS, monotouch_macos, Debug (static registrar).

Framework version

The current failure is source-qualified at a547025bd302e4bfb573d2d35c54709f86f29217; the historical failure/control use actual tested source 3dbe7db13ce22a5655fc6f56f671c7cab48c3892. The exact selected build SDK and full dotnet/runtime checkout are not established by this native test's original case output; they are not borrowed from another job.

Affected platform version

macOS CI Debug/static-registrar configuration. Exact host minor/build and a shared worker origin are not asserted without an own matched diagnostic. Worker identifiers and addresses are not published.

Description

The exact native FileUrl write returns false before the second metadata-detection call in Xamarin.Mac.Tests.NSPasteboardTests.DetectMetadataTests_SomewhatStronglyTyped. There are 2 confirmed original NUnit failures across 2 distinct monitored PRs.

These are distinct original cases, not TestSummary group counts, cleaned/VSTS XML aliases, skipped results or two retry requests. The historical run's queued metadata head was 24afa7e62a46e7c07783c4dd24ad22804a57f02e, but its own successful source reset independently proves the actual tested 3dbe7db... head shown above.

At both exact failed heads the fixture is the same Git blob, 760b82a1ee23cd322543c82f168c79dbeef9beb7. It creates a unique pasteboard, clears its contents, then asserts that SetStringForType for NSPasteboardType.FileUrl returned true. The original failures are at that assertion, source line 440, on the internal loop's first iteration.

The loop retries an empty metadata result after a successful write. It does not retry this earlier false native write. The internal iteration is not an Azure DevOps retry request. A shared system-clipboard race, timing cause, permission/security policy or particular worker defect is not established.

The historical investigation independently joined two initial automatic executions on the same actual source and the same Debug/static-registrar configuration: run 15730505 failed this original named case, while run 15730544 passed it at 2026-10-19T08:45:42.8669910Z. That bounded same-source control supports the flaky classification; it is not a permanent fix, whole-request recovery, monitor retry or budget refund.

Twelve complete open-and-closed searches covered the stable signature, exact test name, FileUrl, SetStringForType, the false-write assertion and component fragments. The full bodies, structured closures and complete non-ignored histories were inspected. Closed #25446 reports the later DetectMetadata #2 count assertion returning 0 instead of 1 after the write; this failure occurs before that call and is not being treated as that closed root or a reason to reopen it.

Steps to Reproduce

1. Inspect either linked source-qualified run's HtmlReport-simulator_testsmonotouch_macos-1, Debug (static registrar).
2. Read the original test-Mac-*.xml case, not its cleaned/VSTS duplicate rendering.
3. Confirm SomewhatStronglyTyped DetectMetadata #2 set (attempt 1), expected true, actual false, before the next DetectMetadata call. No new local reproduction or CI retry is claimed.

Did you find any workaround?

No validated workaround or exclusive native initiating condition. No monitor retry, source change, approval, SDK/cache/feed repair, worker probe/reset, privacy/security-policy change or remote deletion was performed. Retry capacity remains uncertified because complete all-actor accepted-request history is unavailable; lifetime and exact-head limits are not reset or refunded.

Relevant log output

SomewhatStronglyTyped DetectMetadata #2 set (attempt 1)
Assert.That(pasteboard.SetStringForType(..., NSPasteboardType.FileUrl.GetConstant()), Is.True)
Expected: True
But was:  False

The original XML identities, result clocks, exact fixture source and own source-reset evidence were verified. Artifact retention is limited. Full logs, raw commands/environments, machine paths, worker identifiers, addresses, process IDs and diagnostic archives are not published. No body-only issue-specific diagnostic checklist applies to a new issue.