Undefined index: in commerce_discount_default_rules_configuration() when update or cron is run

I see this too, with each cron run.

I get this same error as the OP, running either 7.x-1.0-alpha4 or 7.x-1.0-alpha4+1-dev, reproducible everytime cron or update is run.

Commerce 7.x-1.9+7-dev (2014-Apr-28)
Drupal 7.30

@dave bruns are you still getting this, specifically every time update is run, or have you found a way to resolve this? This module has a fairly high usage and this is the only report I find. I've tested disabling related modules (commerce_coupon, commerce_discount_extra), or disabling various discounts or coupons, resulting in no difference.

Reproducible every time update or cron is run (update runs cron).
Notice: Undefined index: in commerce_discount_default_rules_configuration() (line 24 commerce_discount/commerce_discount.rules_defaults.inc)

I also have no problem with functionality, but would really like to not have this notice after update is run.

The more disturbing thing is getting the notice running update.php, and the mystery why only 2 of us are reporting this out of a rapidly growing 7000+ installs.

@dave bruns, do you get the notice on running update too? I get it right on the screen where update finishes, not just reports/dblog. No change with the new dev, nor with a recent update to Commerce Coupon (using v2). My discounts and coupons work flawlessly.

@dave bruns Thank you! I had a former discount that I had remade and all I had to do was delete it directly from the database. All better!

Thanks guys! You made my day! :-)

Worked! Found an old discount lingering in the db. Deleted and fixed. Thanks!

Also having this issue. Is there a permanent solution for this so that I don't have to delete old discounts manually from the database? : - )

I have the same issue.

Can confirm this issue as well. Manually deleted old entries from the database and it seemed to take care of it... for now.

Still seems to be an open issue. There is a way to resolve the symptoms (as noted above), but the underlying problem is still that the commerce_discount_offer does not have a bundle value. This can also cause problems during checkout, since the rule will not be able to execute.

Yeah, rebuilding the Rule(s) by hand is a great temporary fix, but has no bearing on the underlying issue. @kscheirer and I are investigating this as it seems to affect multiple use cases:

1) Rules-based Discounts (in our usage it's always a percentage discount) suddenly becoming corrupted, and losing any reference to a commerce_discount_offer; The end result is a blank "Action" in the export array, which in the user interface manifests as "Unknown action ."

2) (This is more an assumption) Commerce Coupon Discounts suddenly being removed from Orders upon Checkout completion. Related issue: #2328357: Discount amount goes away when checkout completed.

It seems to be something that pops up on occasion, sometimes at update.php, sometimes at the management page; but the end result is the same: the Discount Offer reference gets removed, and the discount Rule(s) are therefore never fired.

Are you two using commerce_entitycache?

Not using Commerce Entitycache, but we are using Entitycache.

Just thought I'd check because I've had nasty fatals due to it. Entity cache should work as its only known entities.

Just thought I'd check because I've had nasty fatals due to it. Entity cache should work as its only known entities.

I got this again, thanks to a Discount Rule that had somehow become broken. Basically the Commerce Discount Offer (which is referenced in a field on Commerce Discount) was looking at the wrong target ID. So when the defaults get built there is no Offer to find.

I'm not sure what could cause this loss of parity, but it happens for us on occasion with percentage discounts. I can reproduce it with that same Rule by deleting the Action (which becomes "Unknown," thus making the rule "dirty") and then reverting the Rule.

So I'm not sure if this is a caching thing or some kind of race condition, where if you re-save a Discount (or its Rule / Pricing Rule) the target_id gets changed because it somehow gets deleted and added again, but that is what seems to have happened in these cases on our site.

One more: while clearing all caches, I got this (new) error:

Fatal error: Can't use method return value in write context in commerce_discount/commerce_discount.rules_defaults.inc on line 26

I've been adjusting cache-related items in settings.php (related to Stampede Protection) and I think in doing so exposed this error. It seems that it's the same line, where it is essentially attempting to assign a value at the same time as it retrieves one. Changing it to the below - splitting it into two separate lines - fixed it for me:

  $type = $types[$discount->type];
  $offer_bundle = $wrapper->commerce_discount_offer->getBundle();
  $offer_type = $offer_types[$offer_bundle];

When do a Drupal Database Update I get
• Notice: Undefined index: in commerce_discount_default_rules_configuration() (line 24 of /Library/ [path part removed] /profiles/commerce_kickstart/modules/contrib/commerce_discount/commerce_discount.rules_defaults.inc).
• Notice: Undefined index: in commerce_discount_default_rules_configuration() (line 24 of /Library/ [path part removed] /profiles/commerce_kickstart/modules/contrib/commerce_discount/commerce_discount.rules_defaults.inc).

I tried various methods but each time I delete the DB entries in rules_config they came back when running cron or Drupal DB Update. So it had to come from somewhere, in fact it seems there is a rebuild process for the discount rules (no idea which files does it), and uses the commerce_discount.. entries to rebuild this.

For anyone getting stuck with cleaning rules. I disabled all discount rules and started to play around in the DB to see how it may work, would be helpful if someone can double check and confirm this. Goes without saying, don't do this on the production server...

I deleted all the DB records in
- in rules_config
- in commerce_discount
- in commerce_discount_offer
- in commerce_discount_usage

In my case I could not see which duplicate entry was linked with what due to the duplicate machine, user and settings names. I would advice not to use 'clone' as it clones the machine name plus all other details and after getting stuck you cannot change most of this and also lost the proper table references (still there on SQL level but really hard unravel by comparing the record one by one), it can be solved via SQL but is not easy. There should be a module which gives power to sort this out and avoids people SQL-ing about.

Next I refreshed the discount page. All discounts are gone
Next i did a cron and a Drupal DB update run. Discount Rules are no longer rebuild by either of the processes. Solved!!
Then rebuild via the Drupal Discount all the discount rules - and as said - avoid cloning...

But how does this relate to existing discount entries in the order pages?? This needs some investigation to be sure no new errors appear in other areas.

Can someone confirm this to be a safe method?

commerce_discount_default_rules_configuration() is called during Cron or cache clears as part of the Rules rebuild feature. So anytime Rules are rebuilt that function will get called.

I haven't figured out the root cause yet, but I did find that my fix in #23 prevented some related errors from occurring (mainly in that it would return an empty string due to the way this was assigning value to an item in an array). I'd suggest changing those lines as I've done - I can provide a patch if others need it.

I have not used the patch, I need to have first a good scope how it relates to the drupal core, kickstart and module updates. Not so long ago I used a patch which caused problems after an update but forgot that patch and took me days to sort out then realizing its the patch. Developers can handle this, people who run drupal but with less insight in the code build may run into trouble with patches, I advise them to stick to approved module updates.

That's why I hope someone can create a proper module to repair / delete the erroneous discount rules (well any rule) and should be the way forward to support drupal users.

If you're not a developer, then please don't close Issues like this which pertain to people who are trying to solve the root cause of your problem.

I have same issue:

I configured my discount with https://www.drupal.org/project/commerce_discount_product_category

My product has a taxonomy reference field. If a product tagged with the 10% tag, 10% discount will be added. Simple.

If I re-save one of defined discount, the rule for this discount will created. After a CC ALL, the rule disappears. It's little bit frustrating to save all discount rules after every Cron run… :)

I tried with rules 7.x-2.9 and 7.x-2.7 too, but the problem does not depend of the version of the rules module. So, I think, this module unusable in without fix this issue (should be critical)

Another one: if a rule exists - after I re-save the discount - then I edit this discount rule, it's status become overridden. After this, the rule does not disappear after cache clear. But, when a rule is overridden, you can't edit the discount, the edit page says: The rule associated with this discount is overriden, making it impossible to edit the discount.
(yeah, another issue: overri_d_en)

I tried to clone the discount rule (10% -> 10% cloned) - It's fine as a workaround. This cloned rule can be added to a feature too.

I hope, my comment helps to fix this issue. I hope, I will have time at the weekend, to create fix to solve this problem.

@Denes.Szabo: I don't think this is the same issue as what is discussed in the original post. Your issue sounds like an issue specific to the Commerce Discount Product Category module, so you should open a ticket there.

EDIT: In fact I think these issue may be related. I can reproduce this.

I'll work on figuring out why and if I can I will post a patch to the appropriate module, once I figure out the responsible caller.

EDIT AGAIN: I deleted the Product Category condition then recreated it, and now I can't reproduce. I've seen this issue before but I wonder if something in the latest Discounts -dev has fixed it.

Sorry for closing torgosPizza, I closed my own case... will be more careful.

@torgosPizza You are right, I need to debug my site without the Commerce Discount Product Category module. But, the notice about missing index appears on my site, I thought first, it related.

I just fixed the undefined index, patch attached.

But, It can't solve the real problem: sometimes there is a commerce_discount_offer which has no bundle. I do not know, how it can be. But the notice gone.

Do the "missing bundles" only happen with Discounts that used the "Commerce Discount Product Category" module? I can't say with 100% certainty but I have this feeling that the CDPC module is missing something to hook it more fully into the Discount system's dynamic "Action" rule generation. Or perhaps it's a race condition, or a field caching issue.

I say this because when I have dug down, it appears that the "Action" for the discount is removed, and needs to be reselected / reconfigured. So at some point in the cache-rebuild the available Actions are reset or deleted. I've noticed that the values in the field data (in the db) also change - the target_id for the discount reference is not the correct ID of the reference as configured in rules_config.

Hope this helps us get closer to an answer. I think your patch is good if not a bit long (since we are now nesting the actions inside the condition). To be honest if we are going to check for an empty value from getBundle() we should issue a watchdog() entry or throw an exception so that site admins know there is an issue.

This may not help the overall issue here but I've essentially committed #32 with some improvements (mostly hate nesting if we don't have to). Also got rid of the unnecessary array_keys() call and check.

Leaving this open anybody has a response to #34 Will mark fixed if nobody replies in a week or so...

I'm using an old version of commerce_discount, and I couldn't get the patch in 35 to apply cleanly because of line number differences. Here's the same patch in 35 rolled to match the version we're using from revision 152a7fa

You likely do *not* need this patch if you can install the dev release.

Closing this as mentioned in #37

@Greg Boggs consider moving to the dev release.

while the error message is fixed, I think we still want to make sure that commerce_discount_offer in fact has a bundle type - or is there some case where its ok not to?

There should be no reason an offer doesn't have a bundle.

But I've had some issues of late where it seemed to go missing which isn't cool, and cache clear fixed it which also isn't helpful.

Under normal circumstances it would not be there if the type info definition was deleted.

Based on 41 and 42

@kscheirer I'm not sure the actionable task here. Considering closing this and opening up a follow-up but need more details on a solution. The actual issue in the IS is solved, the one I mentioned in #42 is a broader issue which I can't reproduce.

Putting back to fixed.

commerce_discount_offer in fact has a bundle type

The following code defines that the entity type supports bundles.

  $items['commerce_discount_offer'] = array(
    'label' => t('Commerce Discount Offer'),
    'controller class' => 'EntityAPIControllerExportable',
    'entity class' => 'CommerceDiscountOffer',
    'base table' => 'commerce_discount_offer',
    'fieldable' => TRUE,
    'entity keys' => array(
      'id' => 'discount_offer_id',
      'bundle' => 'type',
    ),
    'bundles' => array(),
    'module' => 'commerce_discount',
    'metadata controller class' => 'EntityDefaultMetadataController',
    'inline entity form' => array(
      'controller' => 'CommerceDiscountOfferInlineEntityFormController',
    ),
  );
  foreach (commerce_discount_offer_types() as $type => $info) {
    $items['commerce_discount_offer']['bundles'][$type] = array(
      'label' => $info['label'],
    );
  }

Here's what entity_info does if bundle is empty

        // If no bundle key is provided, assume a single bundle, named after
        // the entity type.
        if (empty($entity_info[$name]['entity keys']['bundle']) && empty($entity_info[$name]['bundles'])) {
          $entity_info[$name]['bundles'] = array($name => array('label' => $entity_info[$name]['label']));
        }

No action items here.