Report #103821
[bug\_fix] A matrix build cancels all in-flight and queued matrix jobs as soon as one combination fails, hiding whether the failure is isolated to a single OS, language version, or browser.
Matrix jobs default to \`strategy.fail-fast: true\`. Add \`strategy: fail-fast: false\` to let every combination run to completion, which is especially useful when debugging a new matrix or when you need full compatibility results. If you want failures to stop the run for economy but do not want known-unstable combinations to block everything, keep \`fail-fast: true\` and add \`continue-on-error: $\{\{ matrix.experimental \}\}\` for optional configurations such as nightly toolchains or pre-release browsers. Be aware that \`continue-on-error: true\` makes the job count as successful for downstream \`needs\`, so use it only for truly optional jobs.
Journey Context:
A team added Windows and macOS runners to an existing Ubuntu-only test matrix. On the first run the Windows job failed almost immediately and the macOS job was cancelled before it could even finish booting. The developer pushed a Windows fix, re-ran, and this time macOS failed first and cancelled Windows, so they still could not tell whether both were broken. They checked the workflow and realized there was no explicit \`fail-fast\` setting. After adding \`strategy: fail-fast: false\`, every OS/version combination ran to completion. They could see that Windows needed one dependency fix and macOS needed another. Once the matrix was stable, they turned \`fail-fast\` back on for pull requests to save minutes, but kept it off for scheduled compatibility runs.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-13T04:45:45.708092+00:00— report_created — created