Table information not available for the 'coupons' field. After Updatedb

@sooraj sahai I met the same issue like you when I only wanted to enable commerce_promotion when commerce_cart is not enabled.

The error message was gone when I commerce cart is enabled before commerce promotion. Using Drupal 9.0.7.
Seems like it's a hidden dependency on Cart when using Promotion.

Sorry, setting wrong status of issue.

Just got the same issue, now my site is broken.

It seems promotion did not install correctly so there is no table created, now I can't uninstall commerce_promotion with drush as it fails because the table doesn't exist.

Not sure how to reproduce this unfortunately... Try disabling it manually using the instructions from https://www.drupal.org/node/157632. And re-enable it?

@danharper: Did the solution from the link work?

I recently ran into this on my d10 site, using a fresh install. I tried the commerce_cart workaround, and got it working.

When installing the commerce modules locally, exporting the config, and importing it on staging, this also happens.

This could be considered critical if I'm provided reproducible steps... The initial report is 4 years old and seems to affect a small portion of users, probably under specific circumstances, so downgrading the ticket priority to "normal".

@maartendeblock: Could you provide additional details / reproducible steps on a clean install please?

Stills happens when deploying in a drupal 10.4.6.

Reproduction: install Canvas (drupal.org/project/canvas) before commerce_promotion.

Canvas's block plugin manager decorator eagerly rebuilds all block-plugin definitions (including Views block derivatives) synchronously on every entity_field_info cache tag invalidation. commerce_promotion's own entity/field schema install fires exactly that cache tag mid-install - before the coupons field's table exists - and Canvas's eager rebuild walks straight into it. Without Canvas active, Drupal's block-derivative discovery is normally lazy, so the bug stays a rare edge case instead of firing reliably.

Root cause: CommerceEntityViewsData::addReverseRelationships() (src/CommerceEntityViewsData.php:516) calls $this->tableMapping->getFieldTableName($field_name) with no guard for a field that's declared in code but not yet schema-installed. Core's DefaultTableMapping::getFieldTableName() throwing in that case is correct, deliberate behavior - Commerce just doesn't handle it. A defensive check (e.g. skip the reverse relationship, or catch and log, if the field's storage isn't installed yet) would fix it without changing behavior for the normal case.

Confirmed on Commerce 3.3.8 / Drupal 11.4 / Canvas 1.10.0 / PHP 8.5.7 .

Can confirm that the issue is reproducible by the steps provided in comment #14. Also, can confirm that changes in the MR resolve the issue, and a new test fails without changes in the CommerceEntityViewsData class

Merged thanks!