Windows Swift 6.2: MistKitTests emit tip-over returns (blocks #392 / PR #485)

[leogdion]

Summary

Build on Windows (windows-2022, swift-6.2-release, 6.2-RELEASE) fails again with the
MistKitTests emit tip-over first characterized in
.claude/docs/research/windows-6.2-ci-failure-462.md (#462). This is not a new class of
failure — it is the same one, re-triggered because the test module grew.

Signature (confirmed, run 34900391337, head 21cb633)

• Emitting module MistKitTests — 0 occurrences
• Emitting module MistKit, MistKitOpenAPI, and every dependency — present
• No error: and no stack dump anywhere in the log
• Compile reaches [1194/1203], then bare Process completed with exit code 1

Windows 6.1, Windows 6.3 (both 2022 and 2025) and every other platform are green on the
same commit.

Where the threshold sits

MistKitTests total source lines, measured per head of PR #485:

Head	Lines	Files	Windows 6.2
eea8824 (pre-rebase)	24,858	258	success
a70f007 (post-rebase onto beta.6)	25,612	261	fail
21cb633 (after body-gating 8 tests)	25,649	261	fail

So the tip-over is somewhere between 24,858 and 25,612 lines. Two contributions landed
in that gap: #484 (Make FieldValue lists homogeneous via Arity) added ~369 lines to the
test module on v1.0.0-beta.6, and #392's encrypted-field tests added the rest.

Note: v1.0.0-beta.6 has never run the MistKit matrix (gh run list --branch v1.0.0-beta.6 --workflow MistKit is empty — its own pushes only ran MistDemo Integration and
CodeQL). So whether beta.6 alone is over the threshold is untested, not established.
Worth running the matrix on beta.6 directly to find out, since that determines whether this
is inherited or specific to #392.

What was already tried on #392

Body-gating per the documented mitigation — .disabled(if: Platform.isWindowsSwift62) on the
suite plus #if !(os(Windows) && compiler(>=6.2) && compiler(<6.3)) / #else Issue.record(...)
around the body — applied to 8 tests across RecordOperationConversionTests+EncryptedValidation,
LoggingMiddlewareTests+DebugBodyReplay, and the moved conversionTagsEncryptedLocation.
That shaved too little: 25,612 → 25,649 (the gating adds lines even as it removes emitted IR)
and the job still fails. The gating is correct and matches convention; it is simply not
sufficient on its own.

Largest ungated test files (candidates if body-gating is continued)

FieldValueConversionTests+Lists.swift (716) and
AuthenticationMiddlewareTests+TokenRotation.swift (224) are already gated. The largest
ungated ones:

Lines	File
224	Authentication/Credentials/CredentialsTokenManagerTests+PublicDatabase.swift
218	Models/FieldValues/FieldValueConversionTests+ResponseTypes.swift
218	Authentication/InMemoryTokenStorage/InMemoryTokenStorageTests+ExpirationTests.swift
217	CloudKitService/BatchChunking/CloudKitServiceTests.BatchChunking+LookupAllRecords.swift
215	Models/Zones/ZoneMetadataTests+ZoneInfoConversion.swift

Options

1. Package.swift #if os(Windows) exclude: — the research doc records this as the one
   remedy proven to work (run 33657978639 went green). Rejected in Web auth token rotation (X-Apple-CloudKit-Web-Auth-Token) is never consumed #462 as "broader than
   needed" because it drops those sources on Windows 6.1/6.3 too. Could be narrowed with a
   compiler-version condition.
2. Continue body-gating the files above until emit succeeds. Preserves coverage on
   6.1/6.3, but the tip-over cannot be reproduced locally, so each attempt is a blind ~10-minute
   CI round-trip.
3. Split MistKitTests into two targets so neither module alone crosses the threshold.
   Structural, but addresses the cause rather than the symptom — the module is 261 files and
   only grows.
4. Drop Windows 6.2 from the matrix — 6.1 and 6.3 both pass; 6.2 is the only affected
   toolchain and the bug is Apple's, not this package's.

Option 3 or 4 seems more durable than continuing to shave lines, but that is a call for the
maintainer.

References

• Research: .claude/docs/research/windows-6.2-ci-failure-462.md
• Memory: .claude/memory/reference_windows_62_mistkittests_emit_abort.md
• Original issue: Web auth token rotation (X-Apple-CloudKit-Web-Auth-Token) is never consumed #462
• Blocking: PR Encrypted fields: isEncrypted support, explicit type tagging, and ADP findings #485 (Research Encrypted Fields #392)

[leogdion]

Windows 6.2 is now non-blocking — symptom masked, cause unchanged

To unblock PR #485, build-windows in .github/workflows/MistKit.yml now carries:

continue-on-error: ${{ matrix.swift.version == 'swift-6.2-release' }}

Scoped to the 6.2 matrix entry only — 6.1 and 6.3 still gate merges on both windows-2022 and
windows-2025.

This changes nothing about the underlying bug. The job still runs and still fails; it just
no longer fails the workflow. Everything in the issue body above still stands.

One side effect worth recording: the lint job was also being skipped by this. It declares
if: ${{ !cancelled() && !failure() && ... }} with needs: [build-ubuntu, build-macos, build-macos-platforms, build-windows, build-android], so a red Windows 6.2 made Linting
report skipping rather than running. With 6.2 non-blocking, linting executes again — so this
was suppressing a real check, not only adding a red mark.

Please remove the continue-on-error line as part of whatever real fix lands here (splitting
MistKitTests, or dropping 6.2). The comment above it in the workflow points back to this issue.