Problem/Motivation

In recent meetings, we have decided to move away from denormalizing AI responses in our module (by using Schemata and custom denormalizers). Instead, we'll put the onus on developers to use the process phase of the migration to target the data they want within the raw AI response structure.

Proposed resolution

  • Remove module code that denormalizes AI responses.
  • Remove custom denormalizer class(es).
  • Ensure that the structure passed out of the source plugin retains the structure returned from the LLM.
  • Update/add process plugins in example migrations so that nodes are still created correctly.
  • Update tests as needed.
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

majorrobot created an issue. See original summary.

dmundra’s picture

Assigned: majorrobot » dmundra
Status: Active » Needs review

Reviewing the MR

dmundra’s picture

Code changes look good. Testing it out now. So much simpler, nice!

dmundra’s picture

Simple content migration worked fine other then the body not saving the text format. For complex content migration the description field did not come back from AI with any data. It might be a prompt issue. I am in favor of approving and merging.

dmundra’s picture

Assigned: dmundra » muriqui

For field format maybe hard code full_html text format in the migration.

Handing over to @muriqui for additional code review.

majorrobot’s picture

* I've added the formats to the migration yml.

* I was also seeing an issue where the AI provider was responding with invalid JSON (too many closing brackets). So, I've updated the default prompt slightly.

* I also got Claude to figure out why we weren't getting field_description back in the response. It turns out the sample pages were updated to use a web component around the description, and the HTML Sanitizer sanitized it out. I've updated the yml to allow the component.

This is ready for you @muriqui!

muriqui’s picture

I think these changes look really good. Building a new migration using the AI source plugin feels a lot more straightforward now. Just a few comments:

  • For the migration config files, the get process plugin is the default, so you could shorthand those as (for example) title: attributes/title instead of
    title: 
      plugin: get 
      source: attributes/title
    
  • I also ran into the problem of json_decode failing because the provider responded with an extra closing brace. I tried adding on to your change to the JSON Schema Rules in the default prompt by appending "In particular, make sure that there are not extra closing braces at the end of the output." and that seemed to stop it (at least for my test run).
  • Did we lose the request caching? I looked like it was making a new request to the provider every time I ran it.
  • I also got an exception when I tried rolling back the migration: Failed to log error: TypeError: Drupal\Core\Database\StatementWrapperIterator::__construct(): Argument #2 ($clientConnection) must be of type object, null given, called in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 441 in Drupal\Core\Database\StatementWrapperIterator->__construct() (line 38 of /var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php). #0 /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php(441): Drupal\Core\Database\StatementWrapperIterator->__construct() Don't know if that's caused by the MR or just an unrelated bug that needs ticketing.

Overall, I'd say we can merge this to unblock other work and follow up on any issues in other tickets.

dmundra’s picture

Assigned: muriqui » majorrobot

I think in the latest update of core the rollback error disappeared for me.