Mismatched field definitions after address upgrade

Same problem here.
Some more detail, in case it's helpful --

Error
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Order report
The Address field needs to be updated.

Yesterday I used composer to update Drupal core-recommended from 10.1.6 to 10.2.2, and drupal/commerce from 2.11 to 2.37. This introduced a new dependency - commerceguys/addressing ^2.1.1.

Does this bug belong in commerceguys/addressing or elsewhere?

No, it's an Address bug for sure.

Unfortunately, I have no time to chase it, someone from the Commerce (Reporting) side will have to take a look.

However, that method only reports fields on fieldable entity types

All content entity types are fieldable.
The OrderReport entity type therefore is fieldable. I don't see where the address field is defined.

Found it:

$fields['billing_address'] = BundleFieldDefinition::create('address')
      ->setLabel(t('Address'))
      ->setDescription(t('The billing address.'))
      ->setCardinality(1)
      ->setDisplayConfigurable('view', TRUE);

The Address update function looks fine and should have updated the billing_address field. Not really sure what happened, don't really have time to dig further right now... But at first glance, the code looks good. Can you check if the actual schema was updated (i.e: do you have the address_line3 column?)

Attaching a screenshot of the result of the following code:
$entity_field_map = $entity_field_manager->getFieldMapByFieldType('address');
@znerol: As you can see, the order report field is found:

Execute the following code in an update_hook on any custom module or using drush ev for cli. It will fix all the issues related to the Mismatched field definitions for all entity types.

   $entity_type_manager = \Drupal::entityTypeManager();
  $entity_type_manager->clearCachedDefinitions();

  $change_summary = \Drupal::service('entity.definition_update_manager')->getChangeSummary();
  foreach ($change_summary as $entity_type_id => $change_list) {
    $entity_type = $entity_type_manager->getDefinition($entity_type_id);
    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);
  } 

If you know the entity name then execute the following code.

    $entity_type = $entity_type_manager->getDefinition('<entity_type_id>');
    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);

The assertion that this only fails for non-fieldable addresses is not entirely correct.

Using address 1.x, I added field_my_address to group and profile.
They worked fine.

Once I upgraded address 1.x to 2.0, then I got errors.
Address is not updated on group and profiles also.

Specifically the address_line3 is not added to group, group_revision, profile, profile_revision.

It is added successfully to node and taxonomy.

Here is the error I get in my logs for group:
|http://mysite/admin/group/types/manage/flexible_group/fields/group.flexi...|

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_my_address_address_line3' in 'where clause': SELECT 1 AS "expression"
Jan 27 21:07:29 prime drupal: FROM
Jan 27 21:07:29 prime drupal: "group_revision__field_my_address" "t"
Jan 27 21:07:29 prime drupal: WHERE ("field_my_address_langcode" IS NOT NULL) OR ("field_my_address_country_code" IS NOT NULL) OR ("field_my_address_administrative_area" IS NOT NULL) OR ("field_my_address_locality" IS NOT NULL) OR ("field_my_address_dependent_locality" IS NOT NULL) OR ("field_my_address_postal_code" IS NOT NULL) OR ("field_my_address_sorting_code" IS NOT NULL) OR ("field_my_address_address_line1" IS NOT NULL) OR ("field_my_address_address_line2" IS NOT NULL) OR ("field_my_address_address_line3" IS NOT NULL) OR ("field_my_address_organization" IS NOT NULL) OR ("field_my_address_given_name" IS NOT NULL) OR ("field_my_address_additional_name" IS NOT NULL) OR ("field_my_address_family_name" IS NOT NULL)
Jan 27 21:07:29 prime drupal: LIMIT 1 OFFSET 0; Array
Jan 27 21:07:29 prime drupal: (
Jan 27 21:07:29 prime drupal: )
Jan 27 21:07:29 prime drupal: in Drupal\Core\Entity\Sql\SqlContentEntityStorage->countFieldData() (line 1794 of /var/www/cci-social-12.1.x-d10.1.x/html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

I get a similar one for profile_revision.

Here is one for profile:
Warning: Undefined property: stdClass::$field_profile_address_address_line3 in Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables() (line 1267 of /drupal10.2/html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)

There is no patch here, changing status.

I also got this issue when upgrading from 1.x to 2.x. I found there was a field storage definition (field.storage.profile.address) which indeed didn't get the address_line3 field after the updated.

I've created a MR which contains a new update hook which checks which field storage definitions are missing the address_line3 field, and adds it when needed.

Can we please try to debug the original update function, and fix the problem there, before we introduce update functions with workarounds?

Our main problem here is that none of the maintainers have sites that are affected, so we need a db dump where the problem can be observed, or we need a developer with such a site to do the debugging themselves.

That would be the best solution, but as there is already a released version which only updates the tables partially, an additional update hook would be the most appropriate in my opinion. If really needed, I can try to extract a minimal db dump which contains the problem.

Edit
Let me do a little more investigating.
A distribution is adding a flexible group type and it looks like that is the only group and group_revision that is not being added.

This might be a custom group issue. if so I will let you know.

As I see in the database, the field is added to everything else.

---
I added the MR and installed address.
That worked

But I received the Mismatched error on the status report
I enabled entity_update and ran drush upe --basic

I received this error:

Exception thrown while performing a schema update. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_my_address_address_line3' in 'where clause': SELECT 1 AS "expression"
FROM
"group_revision__field_my_address" "t"
WHERE ("field_my_address_langcode" IS NOT NULL) OR ("field_my_address_country_code" IS NOT NULL) OR ("field_my_address_administrative_area" IS NOT NULL) OR ("field_my_address_locality" IS NOT NULL) OR ("field_my_address_dependent_locality" IS NOT NULL) OR ("field_my_address_postal_code" IS NOT NULL) OR ("field_my_address_sorting_code" IS NOT NULL) OR ("field_my_address_address_line1" IS NOT NULL) OR ("field_my_address_address_line2" IS NOT NULL) OR ("field_my_address_address_line3" IS NOT NULL) OR ("field_my_address_organization" IS NOT NULL) OR ("field_my_address_given_name" IS NOT NULL) OR ("field_my_address_additional_name" IS NOT NULL) OR ("field_my_address_family_name" IS NOT NULL)
LIMIT 1 OFFSET 0; Array
(
)

We have encountered the same issue on a custom entity, a custom block_type and with a commerce product. The initial update hook (9201) will not successfully run because it "Cannot add field 'some_field_name.field_address_address_line3': field already exists."

The MR/Patch does not work for us because the first update hook keeps failing. I agree with @bojanz that "we should try to debug the original update function and fix the problem there before we introduce update functions with workarounds".

I think @rymcveigh view that the original update hook does not work on custom entities is a good one.

How can we improve the update hook to also work on custom entities.

But in my case the address_line3 does not already exist. it is just not there

We might need both a fix for the original update function, and perhaps a 2nd update function for sites that are in a partially mangled state, TBD.

I haven't yet seen this myself, so I have no insights to share from direct experience.

This seems like a blocker to a 2.0.1 release, so I'd love to get this fixed ASAP.

Thanks,
-Derek

I've added a check in address_update_9201 which does not try to add the field again if it already exists. @rymcveigh this will probably fix your error.

I applied the new MR
I used drush to reset the address module update
drush ev "\Drupal::keyValue('system.schema')->set('address', (int) 9200)";
I ran drush updatedb
address_line3 was added to all address fields

Unfortunately, the patch (in its current state) does not work for my custom entity. Here's what I tried:

I tried adjusting the field definition for my entity prior to running a updb with these changes:

$fields['location'] = BaseFieldDefinition::create('address')
      ->setLabel('Location')
      ->setRevisionable(TRUE)
      ->setCardinality(1)
      ->setDefaultValue([
        'county_code' => 'US',
      ])
      ->setRequired(TRUE)
      ->setSetting('available_countries', ['US'])
      ->setSetting('field_overrides', [
        AddressField::GIVEN_NAME => ['override' => FieldOverride::HIDDEN],
        AddressField::FAMILY_NAME => ['override' => FieldOverride::HIDDEN],
        AddressField::ADDITIONAL_NAME => ['override' => FieldOverride::HIDDEN],
        AddressField::ORGANIZATION => ['override' => FieldOverride::HIDDEN],
        AddressField::ADDRESS_LINE1 => ['override' => FieldOverride::HIDDEN],
        AddressField::ADDRESS_LINE2 => ['override' => FieldOverride::HIDDEN],
        AddressField::ADDRESS_LINE3 => ['override' => FieldOverride::HIDDEN],
        AddressField::LOCALITY => ['override' => FieldOverride::OPTIONAL],
        AddressField::ADMINISTRATIVE_AREA => ['override' => FieldOverride::OPTIONAL],
        AddressField::POSTAL_CODE => ['override' => FieldOverride::HIDDEN],
      ])
      ->setDisplayOptions('form', [
        'type' => 'address_default',
        'weight' => 4,
      ])
      ->setDisplayConfigurable('view', TRUE)
      ->setDisplayConfigurable('form', TRUE);

That resulting in this error: [error] Cannot add field 'maf_memorial_field_revision.location__address_line3': table doesn't exist.

I then imported a fresh DB and tried running the updb without altering my field definition and got the same error: [error] Cannot add field 'maf_memorial_field_revision.location__address_line3': table doesn't exist.

I am going to try to trigger a field definition update before the address update and see if that helps. If it doesn't help, I will look at the changes in the MR today and see if I can figure out why this may be happening. Thanks for helping everyone.

I tried to upgrade my custom entities again today using Address 2.0.1 as the base version of the module.

This workflow DID NOT for me:

• Upgrade from version 1.12.0 to 2.0.1 of the address module: composer require 'drupal/address:^2.0' --with-all-dependencies
• run drush updatedb
• Watch address_update_9201 fail with error: Cannot add field 'maf_memorial_field_revision.location__address_line3': table doesn't exist.
• Apply the patch from this MR
• Rerun drush updatedb and watch it pass
• Check the database and see that the address_line3 column was not created

This workflow failed the first time I tried to do an updatedb but passed the second time I ran it. BUT, it did not actually create the line_3 column on the entity table.

• Upgrade from version 1.12.0 to 2.0.1 of the address module: composer require 'drupal/address:^2.0' --with-all-dependencies
• Apply the patch from this MR
• Run drush updatedb and watch it fail with error: Cannot add field 'maf_memorial_field_revision.location__address_line3': table doesn't exist.
• Rerun drush updatedb and watch it pass.
• Check the database and see that the address_line3 column was not created

That made me wonder what would happen if I ran drush updatedb twice using version 2.0.1 of the module without the patch. This did not work. Here is what I got:

• Upgrade from version 1.12.0 to 2.0.1 of the address module: composer require 'drupal/address:^2.0' --with-all-dependencies
• Run drush updatedb and watch it fail with error: Cannot add field 'maf_memorial_field_revision.location__address_line3': table doesn't exist.
• Rerun drush updatedb and watch it fail with error: Cannot add field 'maf_memorial_field_revision.location__address_line3': table doesn't exist.

I tried to apply the patch but it throw an error while running the update.
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'DEFAULT NULL' at line 1: ALTER TABLE "profile__address" ADD "address_address_line3" DEFAULT NULL; Array

It tries to access the key that doesn't exist yet. So I made a small update and it worked for me.

The previous patch is broken, here is the correct one. I can't push updates to the fork so please review.

I'm still getting

commerce_order_report entity type :
The Address field needs to be updated.

with patch #30.

Solution from the #10 helped to fix the error for the Order report.
Used this code in the custom module's update function:

 $entity_type = \Drupal::entityTypeManager()->getDefinition('commerce_order_report');
  \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);

#10 also fixed it for me, with the same code as #33. I seem to have missed that before!

I've updated the fork with the code of #30.

Patch #30 and #33 code solve the error

The current changes in the MR worked for me! Thank you everyone!!!!

I also ran into this issue.

These are the steps that worked for me

1. Adding the MR 46 as a patch
2. reverting back to 9200 update via drush ev "\Drupal::keyValue('system.schema')->set('address', (int) 9200)";
3. rerunning drush updb
4. running the code from #33. I used drush php

I will test the MR in a staging environment to see if it fixes the issue.

I think once the MR is added, I shouldn't have to run code from #33, correct?

Ok tested on staging. Unfortunately I still needed to run #33

 $entity_type = \Drupal::entityTypeManager()->getDefinition('commerce_order_report');
  \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);

Can we add this to another update_hook in the address module? If so, we need to also add a check if \Drupal::entityTypeManager()->getDefinition('commerce_order_report') exists first in case there are sites that do not have commerce installed.

We recently updated our entire drupal stack from address 1.x to 2.x and noticed that the field settings for address are not migrated correct. Sometimes the new "addresline3" is missing, sometimes our entire config of which fields to show/hide/require is lost...
This is a major problem and it seems we cannot fix it anymore. The config is lost...
Or only option is to go through GIT logs of the config files manually and correct this error.
Seems like some more warning is needed?

UPDATE: seems like this is only issue (for us) on profiles and commerce_orders. For node entity types the migration is correct.

Add patch from MR #46
---
It's commerce_store in my case.

This patch resolved two issues I encountered:

The update hook iterates through the $entity_field_map and attempts to add the "address line 3" field to each entity type's corresponding table. However, it encountered an error when trying to update a non-existent entity type, causing the update hook to fail. As a result, re-running the database updates led to a conflict, as the hook would attempt to recreate columns that had already been added. To address this, I implemented a check to verify whether the column exists before attempting to add it, allowing the update to safely skip existing columns.

I was receiving a "The 'commerce_order_report' entity type does not exist." error, despite the commerce_reports module not being installed. To handle this, I added a conditional block to catch this exception and exit the loop gracefully when such a case is detected.

Reuploading file with relevant file name to avoid confusion. That's not really based on MR46.

Claude Code says:

Issues with address_update_9202()

1. Hardcoded to 'profile' entity type only (line 151)

  if ($entity_type_id !== 'profile') {
      continue;
  }

This limits the fix to only profile entities, but the issue (mismatched field definitions) can affect any entity type with address fields (e.g., node, commerce_order, user, custom entities). This looks like debugging code that was left in. By contrast, address_update_9201() correctly handles all entity types.

2. Dead code / illogical ordering (lines 182-189)

  $spec = $field_schema['columns'][$column_name];
  if (!isset($field_schema['columns'][$column_name])) {
      $spec = [
          'type' => 'varchar',
          'length' => 255,
      ];
  }

$spec is assigned from $field_schema['columns'][$column_name] before checking whether that key exists. If it doesn't exist, $spec would already be NULL (or trigger a notice), and the check on the next line would then overwrite it. The isset() check should come first, or this should just use a null coalescing operator.

3. &$sandbox parameter is unused
The function signature takes &$sandbox but never uses it. This suggests batch processing was intended but not implemented. For large sites with many address fields, this could be a concern, though for a simple schema update it's likely fine.

4. Nearly complete duplication of address_update_9201()
address_update_9202() is ~100 lines that are almost identical to address_update_9201(). The only meaningful differences are the profile-only filter and the fallback $spec. This could be refactored into a shared helper, or the logic could be folded into the existing function.

5. Iterates all storage definitions instead of filtering by address fields
address_update_9201() uses array_intersect_key($field_storage_definitions, $field_map) to only iterate address fields. address_update_9202() iterates all $storage_definitions and manually checks getType() !== 'address' — functionally equivalent but inconsistent with the existing pattern.

6. Missing newline at end of file (line 228)
The diff shows \ No newline at end of file.

The fieldExists() fix to 9201 looks good

The guard added in commit 0bbeca7 is clean and correctly placed — it prevents a DB error if address_update_9201 is re-run or if the column was already added by other means.

Recommendation

The address_update_9202() function needs work before it's ready to merge. At minimum: remove the profile hardcode, fix the $spec assignment ordering, and add a trailing newline. Ideally, extract shared logic with address_update_9201() into a helper to reduce duplication.

Confirming that @sagesolutions's steps in #38–39, using the code in #30 & #33, also solved the problem for me.

I've seen this error on a bunch of my sites, and the latest MR fixes it.