Duplicate alias results in a Drupal rendered error message

Tested 📌 Handle data fetching errors in PageInfo component Active and looks like the fix there is great except the error message is now visible as a message in the preview.

Is this still an issue? I can't reproduce it.

What I've found is another issue (recorded in the gif). Here are the steps to reproduce:
1. Create and publish a page with alias /new-page
2. Create a second page, without alias, and publish
3. Now, add the same alias /new-page, expect to have the error message
4. Now try to publish and expect to have the error message in the publish modal.
5. And here the ... issue??... modify the alias to 123 and now you have 2 different errors.

The original issue, allowing to publish different nodes with the same alias, is not reproducible, but here is another (imho minor) issue.

What do you think, @laurii?

It looks like the final step of the issue summary has been solved most likely by 📌 Publish checks validation constraints, but not form validation Active . 👏 However, this issue is actually about the fact that the message shouldn't be visible in the preview. The error should be visible in the review changes panel and there should be a highlight inline the field. I think this issue should focus on just making sure that the message doesn't render and we need a follow-up to make sure that there's some indication of the error on the form.

Oh, gotcha! Thanks @laurii

isholgueras → credited f.mazeikis → .

isholgueras → credited tedbow → .

Maybe we're deleting errors that we don't want to remove from the messenger and wont be shown in following visits to the backend.

We also want to suppress all messages to XB interface.

After chatting with @f.mazeikis and @tedbow, @wim proposed to replace the messenger service right before we're starting to do things, and revert right after the rendering, so all the messages in the bag in Drupal are there but the messages produced by XB are automatically removed and do not interfere between both.

isholgueras → credited penyaskito → .

I'm happy with the code now. Ready to review.

AFAICT there's a reduction in test coverage, the "XB route" detection is incorrect and the decorator is not implemented correctly. All easy fixes though!

Finally: this is missing test coverage, which would've surfaced that incorrect XB route detection 😇

Refactored to use the current route match instead of the request stack, and fixed a bug that caused this to only work when calling ::addMessage().

All good now!

This is simple enough now to not really need test coverage.

Automatically closed - issue fixed for 2 weeks with no activity.