Module cache serves an unresolvable ArgumentParser xcframework — breaks app Test on unchanged source

Summary

The shared module (binary) cache is serving a broken ArgumentParser xcframework that fails Swift module resolution. Any cache-on build that pulls it fails with:

error: unable to resolve module dependency: 'ArgumentParser' (in target 'TuistApp' from project 'TuistApp')
Testing cancelled because the build failed.
** TEST FAILED **

This breaks app.yml’s Test job (tuist test TuistApp) on otherwise-passing, unchanged source, and will hit any other PR/branch that pulls the same cached binary (the cache is content-keyed and shared).

Impact

• The app Test job fails for app/-touching PRs even when the source is green — a hard CI block, not a flake.
• Persistent: re-running the job and rebasing onto latest main both fail identically.
• Shared blast radius: because the cache key is content-based, every consumer pulling the cached ArgumentParser is affected, not a single branch.

Evidence

• Same commit, different result: 75a732f60 passed on 06-24 12:45 and fails 06-25 03:07+. Both runs pull a cached ArgumentParser — the cached artifact changed/broke between those times; the source did not.
• Cold-cache proves the cache is the sole cause: running the test build from source (tuist test TuistApp --no-binary-cache) is green (21 tests, 0 failures, “Test Succeeded”). Cache-on fails with the ArgumentParser resolution error.
• Build / Device Build pass while Test fails, even though all three pull the same cached ArgumentParser — the test build is the one whose module-resolution path trips on the broken xcframework (missing/unresolvable module map).
• Not re-warmed by app runs: app.yml has no tuist cache step (its jobs only read the cache), and the passing run uploaded 0 cache artifacts — so the bad entry is untouched and won’t self-heal from PR builds.

Likely cause (by timing)

• The cache is warmed by cli.yml’s Cache job (tuist cache, pinned CLI 4.201.0-canary.13) on main. The last warm was 06-24 16:06 (Cache job succeeded). The breakage entered the cache in the 06-24 12:45 → 06-25 03:07 window.
• Two PRs merged to main on 06-24 afternoon, both touching cache xcframework packaging — prime suspects:
  • #11472 fix(cli): exclude module-map xcframework headers from search paths (+ backport #11482)
  • #11474 feat(cli): parallelize XCFramework creation during cache warm
• The warm is deterministic (pinned CLI + unchanged third-party dep), so re-warming reproduces the same broken binary under the same hash — it will not self-heal.

Suggested fix

1. Actively evict the bad entry — bump the module-cache version, or purge the ArgumentParser artifact — then re-warm.
2. Confirm #11472 / #11474 aren’t producing xcframeworks that lack a resolvable module map (this is what manifests as unable to resolve module dependency).

Related

Same module-cache reproducibility class as the bundle-size flap in #11488; this is the hard-failure manifestation (broken module resolution) rather than the size variance.

No GitHub comments yet.