A build failure inside a dependency's module scan is the toolchain, not your code
A native build failed while the compiler's dependency scanner analysed a third-party module in isolation, because a toolchain release regressed how it resolved standard library headers during that scan — a phase that runs independently of any project-level build setting, so nothing in the project could have caused or fixed it.
Resurfaces when
- a native build fails inside a dependency
- the error names a third-party module you did not change
- after upgrading the build toolchain
- hand-editing a generated native project directory
- a build error that project settings do not affect
- about to debug a native build failure whose stack points inside a dependency
- reaching for a dependency bump because the error names a module you did not change
The lesson’s retrieval contract, weighted three times heavier than its body. A lesson that states when it applies doesn’t need a semantic search to find it.
The lesson
Some build phases run outside your project's configuration entirely, and a failure there cannot be repaired by changing project settings — which is exactly what the error text invites you to try, because it names one of your dependencies. The cost is not the wasted attempt, it is the workarounds: hand-edits to generated native directories that survive the toolchain fix and cause a different failure later. When the toolchain is the cause, upgrade it and regenerate the generated directories rather than hand-reverting your own patches. Expect a second, unrelated error to appear immediately after; a version change moves several things at once.
The failure that taught it
An iOS build failed at the dependency-scanning step for a third-party animation module, reporting a missing standard library header. The same header compiled fine in a direct invocation, and no project setting affected the scan — the toolchain release had regressed that phase. The resolution was a toolchain update plus regenerating the native directory from scratch, and a different unrelated error surfaced immediately afterwards from the newer version.
How to apply it
Before changing project settings for a build error naming a dependency, check whether the failing phase reads them at all, and check the toolchain's release notes for a regression. When you have applied manual patches to a generated native directory, delete and regenerate it rather than reverting by hand — hand-reverts leave residue that is indistinguishable from a new bug. Record the toolchain version in the entry; that is the field the next person needs first.
Where this claim comes from
- Lessonmedium confidence
A build failure inside a dependency's module scan is the toolchain, not your code
- Distillationmechanism stated
Written from the mechanism, not the incident — which is what lets it transfer to code sharing nothing with the original.
- Scar2 occurrences
2 separate failures, recorded independently at the time. A clustering pass found they shared one cause.
- Evidence2 records
Referenced by content hash, never by path: entry slugs carry client and ticket names, so a lesson storing them could not be published at all. Resolving a hash needs a map that never leaves the machine. An agent running locally traces it with scar_evidence; nothing on this site can.
What happened when it was used
- 9
- retrieved
- 0
- acted on
- 0
- held up
- 0
- did not hold up
Retrieved but never acted on — a demotion, not a neutral result. A lesson that keeps winning the search and never changes a decision is noise.