Improve server-side error handling

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?

This is not an issue to fix the specific error. I opened 🐛 PHP warning on image props without examples Active for that. This issue is to improve the error handling, because I would not expect PHP errors from the small preview iframes to render in the preview canvas. I also would not expect errors to render inside the small preview iframes.

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

This is not so much about rendering PHP errors vs not. This was about where and how those errors should be rendered. For example, the error in the issue summary, is not even something that happens as part of the preview request, it happens on the component preview request. We should improve the error handling so that errors that happen during API requests, never end up in the preview.

#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? 😊

Proposal makes sense. Thank you @wim leers! 💯

Comments 11 through 19 of 📌 Preview entire page not just content area Active 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: [PP-2] 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.

📌 Recover from server-side errors that may happen during rendering preview Active 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:

1. 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 📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active introduced, plus add the necessary infrastructure.

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

Reflecting that 📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active is itself also blocked.

And added more detail about how to imoplement this.

Reflecting that 📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active is itself also blocked.

And added more detail about how to imoplement this.

Extracted the exposing to the client to 📌 [PP-3] Server-rendered component instances failing to render should expose the meaningful error to the XB UI in a structured way Postponed .

Working on this on top of 📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active

📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active 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