Error when blocks placed in layout builder

I will look into this.
Feel free to try out if you can fix this and then we can work on this together.
Any hints in order to solve this is helpful.

When using layout builder, the $block_id is a UUID. Haven't figured out how to fix it yet though.

The fact that the Response block can not be found by the controller is normal: the block isn't saved in the database in the "normal" way, its configuration is serialized and put into the entire blob that is the LB-config.

In order to solve this, there are a couple of options:
1. We force the site builders and LB-users to link the two blocks together by an ID that they need to specify. It's the same way how Facets are connected to Views and their exposed filters.
2. We append the response of the LLM directly to the form block.

Don't know what Frederik prefers or how many users are actually placing the two blocks in different regions (instead of just below each other).

Hey hey - picking this up - will send a solution for QA @lammensj (today)

Quick update from my side:
I reworked this toward a signed locator flow (instead of shipping full block config in requests).

High-level:

• Form sends search_context + search_context_sig.
• Controller verifies signature first.
• After verify, settings are resolved server-side:
  • source=block_entity - load block entity settings
  • source=layout_builder - load section storage + locate component UUID
• Legacy LB blocks (saved before locator metadata) are handled by runtime locator inference from current route entity + component UUID.

If that inference fails, we still have a signed legacy fallback path.
So the main path is now: signed payload -> verify -> resolve canonical config server-side -> execute search.

Testing I ran (and you can run too):

1. Legacy non-LB: works, backward compatible.
2. LB: 1 form + 1 response: works.
3. LB: 2 forms + 2 response blocks: works when form2 is wired to response2 via target ID.
4. Cross-region LB pairing: works.
5. Tampering sanity check: if signed payload/signature is altered, request is rejected (no unsigned fallback path).

Notes:
- search_context still appears as `enc:...` in HTML (expected), but on the new path it carries locator info, not full plain config.

in example:

--

ok this one was a PAIN :) tbh

Testing description

Environment

• Drupal 11.3.9
• PHP 8.4.12
• DDEV v1.25.2
• drupal/ai: 2.0.x-dev (b88de44) — upgraded from 1.4.x-dev
• drupal/ai_provider_google_vertex: dev-2.x (c83e0b8)

Prerequisites

• A working Drupal installation with the drupal/key module installed.
• A Google Cloud Platform service account JSON key file.

Steps

1. Update composer.json to require AI 2.x and the 2.x branch of the Vertex provider:

   composer require drupal/ai:2.0.x-dev drupal/ai_provider_google_vertex:dev-2.x

2. Run database updates:

   drush updb -y

   Expected: one pending update for ai_automators_update_11001.

3. Enable the required modules:

   drush pm:enable symfony_http_client ai_provider_google_vertex -y

   Expected: modules enable without errors alongside AI 2.x.

4. Verify the changes introduced by MR !17 are present in the installed codebase:

   • Open web/modules/contrib/ai_provider_google_vertex/src/Plugin/AiProvider/VertexProvider.php and confirm the setAuthentication() method signature uses $service_account as the parameter name (renamed from $file_location).
   • Open web/modules/contrib/ai_provider_google_vertex/ai_provider_google_vertex.info.yml and confirm it contains core_version_requirement: ^10.4 || ^11.

5. Create a Key entity for the GCP service account at /admin/config/system/keys/add, using the JSON key file as the key value.

6. Navigate to /admin/config/ai/providers and open the Google Vertex AI provider configuration form. Verify that the service account key created in the previous step is selectable from the key dropdown.

7. Save the provider configuration and confirm no errors are thrown.

Expected results

• The drupal/ai module upgrades cleanly from 1.4.x to 2.0.x.
• core_version_requirement: ^10.4 || ^11 is present in the module's info file.
• The setAuthentication() parameter is named $service_account.
• The module enables alongside AI 2.x without errors.
• The GCP service account key is selectable on the provider configuration form.

Actual results

All steps completed successfully. Both changes introduced by MR !17 were already present in the dev-2.x branch, making the patch unnecessary. The module installs and configures correctly with AI 2.x.

Next steps

Check the MR it has failed pipeline jobs.

This comment was produced with the assistance of an LLM

That's a slop review - don't use AI 2.x - it's not released yet.

@csakiistvan - that review probably should be here #3566301: Compatibility with AI 2.x?

Tested the MR on Drupal 11 with ai 1.3.x

Manual testing

All scenarios I can think of passed. Standard block layout works without regression.
- Placing AI Search and AI Search Response blocks in Layout Builder (per-node override) saves and renders without error.
- The AJAX call to /ai-search-block/query returns 200 for LB-placed blocks, the original "Missing required parameter: block_id" error does not occur. Block config correctly stores lb_storage_type, lb_storage_id, and lb_component_uuid, confirming the controller resolves settings via the signed context rather than the config entity ID.
- Tampering the hidden search_context field returns HTTP 400 with no search executed. The page renders cleanly with only AI Search placed and no Response block present.

Code review issues

Issue 1: SearchResponseBlock::build() breaks DB-results under Layout Builder. It still calls loadByProperties() on the block storage to find the paired form block's DB-results config. Under LB there is no config entity to find, so DB-results silently render nothing. Same root cause as the original bug, just in the response block path.

Issue 2: Removing the block_id-only fallback requires a full cache flush on deploy. Pages cached before deploy send no search_context field at all resolveSettings() returns NULL and users get a 400 until caches are warm. This should be noted somewhere over the docs maybe ?

These 2 issues should be addressed before RTBC. The core fix is sound and the signed stateless context approach is tamper-resistant.

AI disclosure: Code review and comment were preped with AI assistance and manually reviewed before posting.