Server-rendered component instances should NEVER result in a user-facing error, should fall back to a meaningful error instead (+ log)

We don't need to improve error handling. We need to figure out how this is possible, given:

### 3.1 `SDC` `component`s

#### 3.1.1 Criteria for `SDC` `component`s

For an `SDC` to be compatible/eligible for use in XB, it:
…
- MUST have `example` for each required prop
…

👆 This means it should be impossible for the error in the screenshot to ever occur.

Which SDC did this happen for?

Fair. But the title is super vague/misleading then. Fixed.

#6: Yep, that's how I interpreted #4, and what I captured in the updated issue title? 😅

That kind of super broad exception+error catching is something that I've seen only happen in "Drupal userland" one other time: in https://www.drupal.org/project/acquia_migrate, see:

1. sort of https://git.drupalcode.org/project/acquia_migrate/-/commit/238a173d454ee...
2. sort of https://git.drupalcode.org/project/acquia_migrate/-/commit/eb881eb8101bb...
3. but especially https://git.drupalcode.org/project/acquia_migrate/-/commit/7931c1f843be9...

We should do a combination of both catching \Exception (i.e. ALL exceptions) and using PHP's low-level set_error_handler() in ApiComponentsController and ApiPreviewController (probably actually in the code that they call) — those two combined would be able to achieve what you describe, @lauriii 😊

Issue summary updated with outline of implementation based on your feedback.

WDYT? 😊

Comments 11 through 19 of #3489302: Preview entire page not just content area are AFAICT essentially re-hashing this issue 😅😬

Also FWIW I've seen errors break the whole page when using the auto-save controller and pushing invalid data - because SDC has a twig function to validate the component and that throws a RuntimeError that is uncaught.

I had a workaround in an earlier version of https://git.drupalcode.org/project/experience_builder/-/merge_requests/430 that turned this off so at least one invalid component didn't break the whole preview.

We may need to revive that here

#11: Curious what you think about the detailed plan I wrote up in #7. What you describe works for SDCs, but won't work for arbitrary component types, whereas #7 would.

This blocks #3502769, see #3502769-4: Auto-saved PageRegions may be invalid, but MUST NOT cause XB's previews to fail..

Note that if we make this also handle JS errors, that a whole class of "oops, application crashed" problems would be guaranteed to be protected against.

#3511888: Recover from server-side errors that may happen during rendering preview already hardened the client side 🤘

Still would like @larowlan's input — accidentally unassigned in #15.

Updating issue title to convey to everyone this bit from the issue summary:

3. js: SHOULD NOT be possible to happen for "code components" — but actually can if there's a JS error dependent on the input ⚠️ If this turns out to be too difficult to do as part of this issue, this portion can be descoped to a follow-up issue.

AFAICT solving the intent of this issue for code components can only be achieved by wrapping each code component in some XB-owned wrapper that catches these problems. See my related comment at #3499919-22: [Meta] Plan for in-browser code components.

#21: @effulgentsia is confident about <astro-island>'s ability to handle most of this for us, and is confident we’ll be able to still intercept the error and render a nice fallback of our own design/choosing.

That means this issue can focus solely on the server-side aspects, which basically means making all the failing tests that #3517966: Failing kernel tests for all ways a component source can fail to render on the server side introduced, plus add the necessary infrastructure.

Given the additions to /xb/api/layout/… responses, this will need to update openapi.yml.

Reflecting that #3517966: Failing kernel tests for all ways a component source can fail to render on the server side is itself also blocked.

And added more detail about how to imoplement this.

Reflecting that #3517966: Failing kernel tests for all ways a component source can fail to render on the server side is itself also blocked.

And added more detail about how to imoplement this.

Extracted the exposing to the client to #3518201: Server-rendered component instances failing to render should expose the meaningful error to the XB UI in a structured way.

Working on this on top of #3517966: Failing kernel tests for all ways a component source can fail to render on the server side

#3517966: Failing kernel tests for all ways a component source can fail to render on the server side is in!

Rebased 👍

Showing it in action 😎

I changed the cta1 prop to be required and this broke an existing component.

I could still update the component props and then it rendered fine again.

Log entry

Only remaining fail is a known issue in HEAD

This MR looks great! I posted some Qs on the MR.

The only things I'm missing:

1. #7.3, aka set_error_handler() + restore_error_handler(). (I realize now that #3517966: Failing kernel tests for all ways a component source can fail to render on the server side did not add explicit test coverage for that.) But … perhaps that's just not really worth it? Because this MR is catching \Throwable instead of \Exception, which means the actually risky subset of errors is already handled?
2. I would like to see the ability to render a different fallback based on isPreview: FALSE|TRUE, because we'll need that per [#3517941].

Keeping at Needs review for @longwave's review — but I'm excited this looks so close! 😄

Addressed all the feedback. Left one item open to discuss an alternate approach. I think the current approach is scoped to just our neck of the woods and feel the alternate approach (decorating the renderer) would probably be overreach.

I'd like @longwave to do the final review here, but this looks great to me 😊

(Let's also add 2 screenshots to the issue summary, one for a crashing component with isPreview: FALSE, one for isPreview: TRUE.)

Added screenaroonies

Added some questions/feedback.

Fixed all my own feedback except for the plugin ID and the user-facing error message, back to RTBC.

Yep, for the user-facing error message, see the parent meta!

Once designers can see this in action (thanks for the screenshots, Lee!), this is much easier to design for 😊

HUGE leap forward for XB’s robustness! 🥳

Thank you all for the excellent work on this one! 😊 👏