Boost: continue Critical CSS generation when a single provider fails unexpectedly

[kraftbj]

Fixes #38217

Proposed changes

• Critical CSS (local/browser generation): when an unexpected error (anything other than SuccessTargetError) occurs while generating CSS for one provider, record it as that provider's error via the existing set-provider-errors data-sync action (UnknownError type) and continue with the remaining providers — instead of re-throwing, which unwound the whole run, set the global state to error, and discarded the run for all remaining providers even though completed providers' CSS was already saved server-side.
• Keep stepsFailed accounting so the existing critical_css_failure / critical_css_success Tracks events remain accurate; the per-provider critical_css_failure event is still recorded.
• Skip recording the error when generation was cancelled (signal.aborted), matching the previous swallow-on-abort behavior.
• Unchanged: SuccessTargetError (per-URL failures) handling, ProviderCssSaveError handling, and the global hard-failure path when the generator library fails to load. isFatalError() still reports a fatal error when no provider succeeded, so the all-failed UX is preserved. No PHP changes needed — Critical_CSS_State::maybe_set_generated() already flips overall status to generated once no provider is pending.

Note: no jest test added — Boost's jest config has no module mapping for the $lib/$features aliases this module uses, so testing it would mean building new test infrastructure; flagging that as a follow-up rather than bundling it here.

Related product discussion/links

• Part of a Boost Critical-CSS resilience pass (audit follow-up); siblings: Boost: keep position-dependent inline scripts (document.write) in place when Defer JS is enabled #49545, Boost: fully remove boost-cache directory on uninstall and make cleanup resilient on very large caches #49546, Boost: stop stripping SVG markup from Critical CSS while keeping style-tag breakout protection #49547.

Does this pull request change what data or activity we track or use?

No. (Existing Tracks events unchanged; the per-provider failure event already carried provider_key.)

Testing instructions

1. Use a free-plan (local generation) site with Boost's Critical CSS module enabled, ideally with several providers (posts, pages, front page, …).
2. Simulate a failing provider — e.g. via a devtools breakpoint/override that throws inside generateCriticalCSS for one provider key, or by temporarily corrupting one provider's URL in the jetpack_boost_ds_critical_css_state option.
3. Click Regenerate Critical CSS in Boost admin and keep the tab open (generation runs in-browser).
4. Confirm: the progress bar continues past the failing provider; generation completes; the failing provider shows its error in the advanced recommendations list while the others show success.
5. Verify stored state: jetpack_boost_ds_critical_css_state shows the failing provider with status: error, the rest success, overall generated; the front end serves critical CSS for successful providers.
6. Regression checks: a per-URL failure (one 404 URL in a provider) still surfaces as a SuccessTargetError recommendation; blocking the jetpack-critical-css-gen chunk still produces the global error state; cancelling mid-run produces no spurious provider errors.

https://claude.ai/code/session_01PgpTrtTCH4hpz6Krh3ssho

---

Generated by Claude Code

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/boost/app/assets/src/js/features/critical-css/lib/generate-critical-css.ts	0/98 (0.00%)	0.00%	4 💔

Full summary · PHP report · JS report

_{Coverage check overridden by Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR .}

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Boost plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.