[META] Robust component instance error handling

All done!

wim leers → credited effulgentsia → .

An interesting error that prevented any blocks to be placed in XB: 🐛 Undefined array key "base" in Drupal\views\Plugin\views\query\QueryPluginBase Active

Tested this now that 📌 Improve server-side error handling Active landed. It seems that the preview rendering is somewhat working now. It would be great if the component was wrapped with the HTML comment so that it would be possible to see what is the name of the component in XB.

It looks like the library and the props forms fail to render → because of the component is erroring. That is at least equally important with not crashing the whole preview. Is there an issue for that already?

I think we could de-prioritize ✨ [PP-4] Present all component instances that fail to render using toasts Active and possibly even 📌 [PP-3] Server-rendered component instances failing to render should expose the meaningful error to the XB UI in a structured way Postponed until we have designs to not have to spend time on implement a temporary solution.

It looks like the library and the props forms fail to render because of the component is erroring. That is at least equally important with not crashing the whole preview. Is there an issue for that already?

No!

But: how did you make that component crash during rendering? It seems like you deleted an SDC, code component or a block plugin, instead of triggering one of the 6 failure modes described at the top of this issue?

If so: what you did is actually not related to this issue, because this issue is focused squarely on rendering of component instances never failing. AFAICT 🐛 Cannot delete JS components due to component depending on them Active should fix both symptoms. If it doesn't, I'll file issues under 🌱 [META] Production-ready client-side data model + internal HTTP API Active .

until we have designs to not have to spend time on implement a temporary solution.

Well … the point of the issue summary's sequencing (which you approved) is to do ✨ [PP-4] Present all component instances that fail to render using toasts Active using Radix UI toasts to spend zero time on a temporary solution → , but to allow the design team to be better informed when designing this.

It would be great if the component was wrapped with the HTML comment so that it would be possible to see what is the name of the component in XB.

That's a trivial change to \Drupal\experience_builder\Element\RenderSafeComponentContainer::handleComponentException(), which is why it was built that way 👍 However, why not just add a data-component-id attribute in addition to the current data-component-uuid?

  public static function handleComponentException(\Throwable $e, string $componentContext, bool $isPreview, string $componentUuid): array {
    \Drupal::logger('experience_builder')->error(\sprintf('%s occurred during rendering of component %s in %s: %s', $e::class, $componentUuid, $componentContext, $e->getMessage()));
    if ($isPreview) {
      return [
        '#type' => 'container',
        '#attributes' => [
          'data-component-uuid' => $componentUuid,
        ],
        '#markup' => new TranslatableMarkup('Component failed to render, check logs for more detail.'),
      ];
    }
    return [
      '#type' => 'container',
      '#attributes' => ['data-component-uuid' => $componentUuid],
      '#markup' => new TranslatableMarkup('Oops, something went wrong! Site admins have been notified.'),
    ];
  }

But: how did you make that component crash during rendering? It seems like you deleted an SDC, code component or a block plugin, instead of triggering one of the 6 failure modes described at the top of this issue?

Oh, perhaps you tested this by doing what @f.mazeikis also guessed over at #3519168-37: Handle components provided by ComponentSources disappearing ungracefully — enables deleting JS components that are in use → , i.e. by deleting a Component config entity by force?

But: how did you make that component crash during rendering? It seems like you deleted an SDC, code component or a block plugin, instead of triggering one of the 6 failure modes described at the top of this issue?

I did not delete a component but I added invalid Twig syntax to a template. The response to /xb/api/v0/config/component is 500 with message: Unknown \u0022nonExistingFilter\u0022 filter.. I would not expect that having a component in an invalid state would lead into the XB UI being unusable which is why I'd like to prioritize it before the steps 3 and 4 here.

I already showed the current error message to Callum and he's going to do some designs around this that might help make the process more efficient. 😄

Will investigate tomorrow what issues this needs. I expected 📌 Improve server-side error handling Active to have handled the /xb/api/v0/config/component case at the very least 😬

Confirmed with @lauriii that it's fine to consider #3518201 and #3518203 as "nice-to-haves".

Assigning to myself to ensure I follow through with issues for hardening against the "red retry" boxes in @lauriii's screenshot in #11.