After updating from 2.x to 3.x: A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: commerce_order, bundle: default, field name: shipments

I am also getting this error when updating Drupal core to 11.3.9.

Could #3045509: EntityFieldManager key/value field map gets out of sync, doesn't recognise bundle fields be the cause?

You're welcome @anybody. I only updated Drupal core to 11.3.9 and received this error. I upgraded Commerce from 2.x to 3.x awhile back. I tried to reproduce this on a vanilla install but could not.

Also getting the error (FieldStorageConfigInterface::getBundles(): entity type: commerce_order, bundle: physical, field name: shipments) after updating to 11.3.9.

I am on Commerce 3.3.5. for quite some time now. I am seeing the error message on my dev stack. First seen it after running the update, but every time I clear cache either via the admin or truncate in the database I see the entry in my logs.

Done multiple checkouts and no errors in the logs or odd behaviors I notice.

I did some further investigation and the fix for me is restoring or importing the missing configuration resolves the issue immediately. Once the field instance exists, cache rebuild completes successfully with no more errors logged.

field.field.commerce_order.{bundle}.shipments
field.field.commerce_order.physical.shipments

Not sure why the field instance was not there to begin with.

I don't think, #9 is the correct solution, because this is a bundle field, see #3071627: Create order shipment field through bundle field definition - not form submission

#9 is definitely not the correct solution. The field is now defined through code, as explained in the referenced issue.
Afaik, this is just a warning (this needs to be fixed ofc, but I don't think this has other consequences)... Commerce shipping 3.x runs fine on a big production website I'm running that was previously on 2.x.

I've added changes that should resolve this issue.

FieldViewsDataProvider tries to generate data for every field configuration related to the field storage. What is interesting is that it takes into account fields created by the entity_bundle_field_info hook to get a list of bundles where this field is used, and ignores it entirely in the cycle and checks only for field configurations. I hope it will be resolved soon in #2898635: bundleFieldDefinitions() are not added in EntityViewsData

There were two ways to fix this warning:

1. Set custom_storage: true in the field.storage.commerce_order.shipments
2. Replace storage configuration with the entity_field_storage_info hook

I was trying to use the second variant in #3071627: Create order shipment field through bundle field definition - not form submission, and remove the field storage configuration with uninstallFieldStorageDefinition method or by removing it as an entity. In both cases, the field table was removed, so I decided to keep the configuration and added persist_with_no_fields: true to make sure that the storage will not be removed with the last field configuration. What I didn't try is to remove the field storage config via the config factory service, which I did in the current issue, and it works well. I would suggest verifying everything before adding it as a patch to any production environment.

Another thing that we have to do for both solutions is to define view data for the "shipments" field. As I mentioned before, Drupal does not generate it for fields defined in entity_bundle_field_info hooks, and we don't want any broken views.

I haven't tested the changes, but is there an alternate solution possible? I'm really afraid by the big MR and don't really want to take the risk (even the slightest) of loosing data... The data loss risk should be considered here.

I'd like to understand why this suddenly became a problem with 11.3.9. I'm seeing the errors in one of the projects I'm working on that's on 11.3.9, but no functionality seems to be affected... So would be great to understand what's going on and see if we could fix this differently...

Adding potential related issues. (Looking at the Drupal 11.3.9 changes, there haven't been many changes since 11.3.8).

What seems to happened here:
- Commerce Shipping 3.0.2 has a post-update (commerce_shipping_update_10303) that removed the per-bundle shipments field configs.
- Drupal 11.3.9’s Views field-map behavior now logs an error when field storage says a field exists on bundles but the matching field.field.* config entities do not.

As an experiment I re-added the field configs. The site seems to work.
But I can't judge what is the right direction here.

- Drupal 11.3.9’s Views field-map behavior now logs an error when field storage says a field exists on bundles but the matching field.field.* config entities do not.

And I think this is a bug, because this ignores declaring fields through the hook.

As a workaround, I ran the update from #20 and just commited the modified / added configs to our config sync folder. That change should be easy to be reverted when we have a solution here.

@jsacksick are you expecting any side effects from that workaround?

re: #20 This workaround goes against the direction of the module as we were explicitly deleting those config objects in favor of the hook so... I can't really guarantee that this wouldn't cause issues later down the road.

We also encountered this error updating from 10 to 11 only. The 2.x -> 3.x upgrade had taken place previously.

@jsacksick What's the recommended short-term solution? Is this safe to ignore until a better solution is found?

Also based on your comment it looks like this should be Needs Work and not Needs Review so I changed it.

We used the workaround I posted in #20 to create the configs and included these configs in yesterday's update. So far, the site behaves well and we're not flooding the logs like we have seen it in the tests before.
For sure we hope for a proper solution here or in core and will remove the additional configs later.

Re: #9

Afaik, this is just a warning

@jsacksick Technically it is not a warning, it is an error, see: https://git.drupalcode.org/project/drupal/-/blob/main/core/modules/views.... Is there any workaround? We are also experiencing this after the latest upgrades (Drupal core 11.3.13, Commerce 3.3.6) and it is spamming our logs and emails, as the core message is emiting an error. Thanks!

I see the issue still on Drupal 11.3.12, Commerce 3.3.6 and Commerce Shipping 3.02.

Imho it should be a major priority and not normal. It's throwing entries to the watchdog, syslog, custom maillog - whatever log-system we're using.

I'll need to circle back to this but haven't had time to properly dig... I agree this is annoying error in the logs that needs to be addressed.

Also running into this.

The reason it happens now is #3045509: EntityFieldManager key/value field map gets out of sync, doesn't recognise bundle fields, which has been backported as a bugfix to 11.3 in April.

For some reason this shipment field exists as a field_storage config entity, but then not as a field_config entity, which I think isn't really valid. Maybe an inconsistency on updated sites? Additionally, this module did not manage the field map as it was meant to, which resulted in the getBundles() call in \Drupal\views\FieldViewsDataProvider::defaultFieldImplementation() returning nothing, so it returned early. Now it proceeds because the field map is now just a cache, built on the field definitions.

It looks like #3564973: Optimize field views data building might have fixed this in 11.4+, as it removes the FieldConfig::load() and replaces it with EntityFieldManager::getFieldDefinitions(). Will try backporting that for our project to see what happens. That said, this could fail later on as views might expect a field_config when it manages to define the views data for it.

observed today during - drush updb and drush cr - when updating a module unrelated to commerce:

[error]  A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: commerce_order, bundle: default, field name: shipments

Running into this issue when using search API. Catalog searches that were previously accurate aren't always returning any or all values any more, and some searches also return these messages in dblog as views errors

"A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: commerce_order, bundle: default, field name: shipments"

There appear to multiple interlated problems with the commerce shipping code:

The following problem cases a WSOD crash:

The following anomaly report appears in the drupal error_log file.

Uncaught PHP Exception Error: "Call to a member function bundle() on null" at {site}/modules/commerce_shipping/src/Access/ShipmentCollectionAccessCheck.php line 43

2026.08.01

I have installed the update_config_entity module and have executed the drush command below, but that does not fix these related problems.

php -c ./php.ini vendor/bin/drush.php update:correct-field-config-storage commerce_order default shipments

I have tried the following suggested fix, but it does not fix the problem:

php -c ./php.ini vendor/bin/drush.php php-eval "\$key_value = \Drupal::service('keyvalue')->get('entity.definitions.bundle_field_map'); \$map = \$key_value->get('commerce_order'); unset(\$map['shipments']['bundles']['default']); \$key_value->set('commerce_order', \$map);"

php -c ./php.ini vendor/bin/drush.php -n -y cr

Uncaught PHP Exception Error: "Call to a member function bundle() on null" at {site}/modules/commerce_shipping/src/Access/ShipmentCollectionAccessCheck.php line 43

That one seems completely unrelated to this issue. This would seem to happen for a deleted order.

Regarding #33

This error is produced on a new site in which there have never been any "deleted" orders.

The error occurred immediately after installing the xray_audit module and then clicking on the xray_audit_insights settings menu item, which apparently initiates code that scans configuration in some way. The result is a white screen of death (WSOD) crash.

(context) The following anomaly report appears in the drupal error_log file.

Uncaught PHP Exception Error: "Call to a member function bundle() on null" at {site}/modules/commerce_shipping/src/Access/ShipmentCollectionAccessCheck.php line 43

Any news here?
https://www.drupal.org/project/commerce_shipping/issues/3588997#comment-... helps us to run our site, but it is not a good state.

@mkalkbrenner: Are you still experiencing the error? Seems to be fixed in newer versions of Drupal (see the patches mentioned in https://www.drupal.org/project/commerce_shipping/issues/3588997#comment-...).