commerce_customer_match_customer_profiles() tries to load all profiles: php runs out of memory [#1910932]

So, here's what's going on on my site:
{commerce_customer_profile} contains about 30K records with uid = 0;
So, any time I'm clearing cache or doing something that fires commerce_customer_match_customer_profiles(), PHP runs out of memory.
I patched the default $limit argument to 25, and the issues goes away.

Do I need to figure out why/how the profiles are getting created with uid = 0?
Profiles seem to be working fine despite this.

Filing this as a bug, but I will re-post to drupalcommerce.org if you feel it's a support request.

edit: uid = 0, not uid = 1

Comment	File	Size	Author
#2	commerce_customer-limit_profile_loading-1910932.patch	1.05 KB	AaronBauman
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

rszrama CreditAttribution: rszrama commented 7 February 2013 at 18:35

lol - Yeah, I'd figure out how you got 30k entries. : D

That said, can you share the patch? Sounds like a reasonable fix.

Comment #2

AaronBauman

he/him

CreditAttribution: AaronBauman commented 7 February 2013 at 19:18

File	Size
commerce_customer-limit_profile_loading-1910932.patch	1.05 KB

This site has 2 different profile types, 9K users, and 25K orders.
So, the 30K number is not far from what I expected.
I'm guessing the issue is having 29K of the 30K profiles are assigned to uid 0.
During cache clear, commerce is trying to load customer profiles by uid and obliterating PHP's memory limit.

Quick and dirty patch attached.

So far I haven't noticed any odd behavior, even though all the profiles are assigned to uid 0.
user_load() still assigns the appropriate commerce_profile even though the uid doesn't match.
So I guess my next question is, why bother with uid at all?

Comment #3

rszrama CreditAttribution: rszrama commented 7 February 2013 at 19:30

Status:

Active

» Needs review

Ahh, you know, I thought it was 30k for uid 1 for some reason. That said, it's interesting to me that you'd have anonymous customer profiles - they should be getting updated to the uid of the order during the checkout completion process. Have you disabled those rules?

And where is the customer profile match code being called for uid 0?

Comment #4

AaronBauman

he/him

CreditAttribution: AaronBauman commented 7 February 2013 at 20:17

the original issue i posted said uid 1 (see edits above), but I checked again and it's actually uid 0.

This is making sense now that you bring up rules.
The assignment rules are not disabled, but the orders in question are created programatically using entity_create_stub_entity() and saved via commerce_order_save().

The only checkout rules being invoked (again, programatically) are 'commerce_cart_product_add' and 'commerce_checkout_complete'.
All the orders in question have a matching uid, even though the profiles for those same orders have uid = 0.
Thinking this through, order->uid must already assigned when the rule commerce_checkout_order_convert gets invoked, preventing the uid assignment action from firing.

Anyway, looks like commerce_customer_match_customer_profiles() is getting called when commerce's rules get rebuilt on a cache clear.
Here's the stacktrace.
(This "cc all" is called from drush, but results of clearing cache through the UI were the same.)

    [0] => commerce_customer_match_customer_profiles : 954 : ~/public_html/sites/all/modules/commerce/modules/customer/commerce_customer.module
    [1] => commerce_customer_options_list :  : 
    [2] => call_user_func_array : 799 : ~/public_html/includes/module.inc
    [3] => module_invoke : 460 : ~/public_html/sites/all/modules/entity/modules/callbacks.inc
    [4] => entity_metadata_field_options_list :  : 
    [5] => call_user_func : 192 : ~/public_html/sites/all/modules/entity/includes/entity.wrapper.inc
    [6] => optionsList : 111 : ~/public_html/sites/all/modules/rules/modules/entity.eval.inc
    [7] => rules_action_entity_create_info_alter :  : 
    [8] => call_user_func_array : 123 : ~/public_html/sites/all/modules/rules/includes/faces.inc
    [9] => __call : 293 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [10] => __call : 1405 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [11] => setUp : 1381 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [12] => __construct : 471 : ~/public_html/sites/all/modules/rules/rules.module
    [13] => rules_plugin_factory : 40 : ~/public_html/sites/all/modules/rules/rules.module
    [14] => rules_action : 2200 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [15] => action : 134 : ~/public_html/sites/all/modules/commerce/modules/checkout/commerce_checkout.rules_defaults.inc
    [16] => commerce_checkout_default_rules_configuration :  : 
    [17] => call_user_func_array : 799 : ~/public_html/includes/module.inc
    [18] => module_invoke : 771 : ~/public_html/sites/all/modules/entity/entity.module
    [19] => _entity_defaults_rebuild : 749 : ~/public_html/sites/all/modules/entity/entity.module
    [20] => entity_defaults_rebuild : 955 : ~/public_html/sites/all/modules/entity/entity.module
    [21] => entity_flush_caches :  : 
    [22] => call_user_func_array : 823 : ~/public_html/includes/module.inc
    [23] => module_invoke_all : 7307 : ~/public_html/includes/common.inc
    [24] => drupal_flush_all_caches : 241 : ~/drush/commands/core/cache.drush.inc
    [25] => drush_cache_clear_both :  : 
    [26] => call_user_func_array : 792 : ~/drush/includes/drush.inc
    [27] => drush_op : 79 : ~/drush/commands/core/cache.drush.inc
    [28] => drush_cache_command_clear :  : 
    [29] => call_user_func_array : 324 : ~/drush/includes/command.inc
    [30] => _drush_invoke_hooks : 198 : ~/drush/includes/command.inc
    [31] => drush_command :  : 
    [32] => call_user_func_array : 165 : ~/drush/includes/command.inc
    [33] => drush_dispatch : 92 : ~/drush/drush.php
    [34] => _drush_bootstrap_and_dispatch : 61 : ~/drush/drush.php
    [35] => drush_main : 16 : ~/drush/drush.php

Comment #5

rszrama CreditAttribution: rszrama commented 13 February 2013 at 07:19

Status:

Needs review

» Fixed

I'm not sure of the best solution here, but it seems a limit is in order and doesn't adversely affect any tests at least. I'm going to up it to 50 and commit (with a similar fix to the product matching functions just to be safe), and for your custom code, I generally recommend using our entity specific *_new() functions and would look into why your uids aren't being set properly. Good luck!

Commit: http://drupalcode.org/project/commerce.git/commitdiff/fdce722

Comment #6

27 February 2013 at 07:20

Status:

Fixed

» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Comment #7

Zac_JH CreditAttribution: Zac_JH commented 28 February 2013 at 00:12

Component:	Customer	» Product
Status:	Closed (fixed)	» Needs work

It took me a while to track this down. But this patch causes an unfortunate result if you have greater than 50 products that can be shown in the product reference field by a product display and you're not using the autocomplete widget.

Perhaps the fix is to amend the function calls in the product reference rather than the limit introduced in product.

Hopefully it'll help other people find this if it's affecting them by adding this text:

drupal commerce product display product reference showing limited 50 products