Default rule configurations are no longer being rebuilt for tax types / rates

The only finger I know how to point at this one is the concurrency issue.

I've run this on a testbot using the install that the testbot created (using the web UI). I've run it on a testbot from the command line. The only thing I haven't yet done is running it manually on the command-line with concurrency. I'll try that now.

The situation here is that only one test is broken, and that test is only broken on the testbot, and then only (AFAICT) when the test is run with high concurrency. (It works fine with manual testing using the command line, drush, or the web UI, and it works fine as such on the testbot)

I've created a clone of commerce in the "Testbot Exercise" project to see what commits might fix this. Test results (with debug) are at http://qa.drupal.org/pifr/test/185179

Essentially, a dummy tax rate is being created in testCommerceTaxUIConfigureTaxRate(), but accessing the rule configuration page seems to be impossible. I appears that the rule didn't get created, or at least the menu entry for it didn't get created.

We could just rewrite this I suppose, but the danger here is that there is in fact a concurrency issue with rules or Commerce. I have added a menu_rebuild() to try to factor that out, but it didn't help.

Looking for suggestions here :-)

The current commit on testbot_exercise is 35604b8, and has this code:

  public function testCommerceTaxUIConfigureTaxRate() {
    // Create a tax rate.
    $tax_rate = $this->createDummyTaxRate();
    $this->assertTrue(!empty($tax_rate) && is_array($tax_rate), t('Dummy tax rate was successfully created'));
    debug($tax_rate, 'Dummy tax rate');
    menu_rebuild();

    // Login with normal user.
    $this->drupalLogin($this->normal_user);

    // Access the configure component page for tax rates.
    $component_page = 'admin/config/workflow/rules/components/manage/commerce_tax_rate_' . $tax_rate['name'];
    debug('Accessing ' . $component_page);
    $this->drupalGet($component_page);

    $curl_code = curl_getinfo($this->curlHandle, CURLINFO_HTTP_CODE);
    debug('Response when accessing rules component is ' . $curl_code);

    // It should return a 403.
    $this->assertResponse(403, t('Normal user is not able to access the component configure page for a tax rate'));

    // Login with store admin user.
    $this->drupalLogin($this->store_admin);

    // Access the configure component page for tax rates.
    $this->drupalGet($component_page);

I updated the test to use UI techniques and have the same #fail. The tax rate apparently gets created successfully, but not the rule that goes with it.

  public function testCommerceTaxUIConfigureTaxRate() {
    // Create a tax rate.

    $this->drupalLogin($this->store_admin);
    $post = array(
      'tax_rate[title]' => t('A tax rate'),
      'tax_rate[name]'=> 'ataxrate',
      'tax_rate[display_title]' => t('A tax rate'),
      'tax_rate[rate]' => .099,
      'tax_rate[type]' => 'example_tax_type',
    );
    $this->drupalPost('admin/commerce/config/taxes/rates/add', $post, t('Save tax rate'));
    $this->assertText(t('Tax rate saved'));
    $this->assertText($post['tax_rate[title]']);

    menu_rebuild();

    $component_page = 'admin/config/workflow/rules/components/manage/commerce_tax_rate_' . $post['tax_rate[name]'];
    debug('Accessing ' . $component_page . ' as admin user');
    $this->drupalGet($component_page);
    $curl_code = curl_getinfo($this->curlHandle, CURLINFO_HTTP_CODE);
    debug('Response when accessing rules component is ' . $curl_code);


    // Login with normal user.
    $this->drupalLogin($this->normal_user);

Tried adding a rules_clear_cache(TRUE) without success:

    $this->assertText(t('Tax rate saved'));
    $this->assertText($post['tax_rate[title]']);

    cache_clear_all('*', 'cache_rules', TRUE);
    rules_clear_cache(TRUE);
    menu_rebuild();

Opened #1321564: Delay in creating rules component menu links? in the Rules queue.

I'm going to propose that we comment out this test until we have a resolution. We need our tests back.

Here's a patch temporarily removing this test. I recommend that we get this committed.

This patch brought the number of #fails down to 12.

Reverting #1267070: Lazy-rebuilding the defaults for exported entities might not be desirable resolves this problem.

Attaching my testing routine, with command lines used.

And we bow down:
Tax administration 596 passes, 0 fails, and 0 exceptions

Full verbose output attached, as if it did any good :-)

Sadly, the tests fail now due to a problem on drupal.org, with project dependency. The dependencies for Commerce are being calculated wrong because an "installation profile" has checked in *all* of commerce, views, etc. as part of the install profile. See #1325658: Please remove all the duplicated modules! You can't just include commerce in your distribution! and #1276914: Contrib module may be considered a dependency instead of core module of the same name and #1325654: Profiles and themes should be excluded

I don't have the privileges to rebuild dependencies unfortunately. But we need a

sudo -u www-data drush pdpp commerce views rules addressfield ctools