magento2: Broken CMS block preview when using identifier in pagebuilder

Summary

When adding a CMS block in a CMS page using the block identifier instead of the block ID, pagebuilder displays following error : “Block with ID: [block identifier] doesn’t exist.” instead of showing preview of the CMS block.

The block renders properly on front-end. There is no way to add a block with his identifier directly from pagebuilder. This issue would only happen if a developer executes a data patch that generates CMS content or directly edit the content in the database.

Preconditions (*)

1. Occurs on Magento 2.4.X (tested on 2.4.3-p1)
2. Tested both on local and Cloud environments

Steps to reproduce (*)

1. Create a CMS Block with any content
2. Create a CMS Page and add previously created CMS Block in the page with the PageBuilder Block component
3. Open cms_page table
4. Find the created page
5. Replace block_id value with the block identifier in the content cell. Example for a block with identifier contact-us-banner : <div data-content-type="block" data-appearance="default" data-element="main">{{widget type="Magento\Cms\Block\Widget\Block" template="widget/static_block/default.phtml" block_id="contact-us-banner" type_name="CMS Static Block"}}</div>
6. Apply changes
7. Refresh pagebuilder page to see error

Expected result (*)

1. The pagebuilder should be able to display a preview of the block content

Ability to load block by identifier was added back in 2017 https://github.com/magento/magento2/issues/10414

From what I’m seeing in the following file, getBlockId function should handle non-numeric IDs (identifiers) : https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Cms/Model/ResourceModel/Block.php

Actual result (*)

1. An error is displayed in the pagebuilder : “Block with ID: [block identifier] doesn’t exist.”, even though the block exists and is rendered on the front-end.

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.