Random fails in UpdatePathTestBase tests

Let's get a few test runs in a see how often it is occurring - interestingly seems to only be 8.1.x so far (and not 8.2.x)

Happened again... https://www.drupal.org/pift-ci-job/331429

Can we make it fail for sure...

Let's include more of the failing tests.

So we have more info and we can cause the fails!

• Drupal\system\Tests\Update\UpdatePathTestBaseFilledTest fails on 8.2.x
• Drupal\field\Tests\Update\FieldUpdateTest fails on 8.1.x

So concentrating on 8.1.x

Let's try bisecting...

Opps this was 5c01c88

@claudiu.cristea you need to apply this patch to the hash so it runs the test a few times.

Let's see if it fixes both things ... although this oddness is given me deja-vu - #2762549: Drupal\field\Tests\Update\FieldUpdateTest, Drupal\views\Tests\Update\EntityViewsDataUpdateTest and Drupal\comment\Tests\CommentFieldsTest fail on 8.1.x

Ok so the issue with 8.1.x is the same as #2762549: Drupal\field\Tests\Update\FieldUpdateTest, Drupal\views\Tests\Update\EntityViewsDataUpdateTest and Drupal\comment\Tests\CommentFieldsTest fail on 8.1.x - even if we committed a revert it is still going to fail :( now to bisect the 8.2.x fail.

Assuming when we opened 8.2.x is good.... here's the test commit to test.

4a95e65086a40187989144a9630b12ab3bb71c62 is the first bad commit
commit 4a95e65086a40187989144a9630b12ab3bb71c62
Author: Nathaniel Catchpole
Date: Tue Jul 19 13:37:02 2016 +0100

Issue #2761403 by Berdir: Move runtime theme registry into bootstrap cache

:040000 040000 c290a369260a1764712a18e8fb79d605715a1f33 8934e4a61a161ee7326227289773cf914b9a14af M core

Let's revert it

Let's makde sure that changing the file doesn't fix....

So the issue that introduced the 8.2.x fail looks like it is #2761403: Move runtime theme registry into bootstrap cache

I fixed the issue summary of #2762549: Drupal\field\Tests\Update\FieldUpdateTest, Drupal\views\Tests\Update\EntityViewsDataUpdateTest and Drupal\comment\Tests\CommentFieldsTest fail on 8.1.x to include the Drupal\field\Tests\Update\FieldUpdateTest test as #46 is conclusive evidence this is the same bug.

Now that #2761403: Move runtime theme registry into bootstrap cache has been reverted I think we can mark this issue as fixed.

Ah looking in all my old fail emails we should also look at Drupal\views\Tests\Update\EntityViewsDataUpdateTest - seems to fail on PHP 5.5 / 8.1.x only so might be the same as #2762549: Drupal\field\Tests\Update\FieldUpdateTest, Drupal\views\Tests\Update\EntityViewsDataUpdateTest and Drupal\comment\Tests\CommentFieldsTest fail on 8.1.x

Okay as suspected Drupal\views\Tests\Update\EntityViewsDataUpdateTest is also #2762549: Drupal\field\Tests\Update\FieldUpdateTest, Drupal\views\Tests\Update\EntityViewsDataUpdateTest and Drupal\comment\Tests\CommentFieldsTest fail on 8.1.x

So marking this issue as fixed again.

Hmm so the revert didn't fix it... :( https://www.drupal.org/pift-ci-job/388205

Maybe we've found the 8.2.x equivalent of core/lib/Drupal/Core/Config/Entity/ConfigDependencyManager.php - a file that any change results in a pass... but I tested that in #69 :(

What is going on... #68 was passing all the time.

Testing again...

Reverting the revert...

So did I get the wrong commit :( both 83 and 84 have now failed... I did the bisect with 30 - but maybe that is not enough - since it is possible to be green with 50... see #83

This actually failed on second re-test :(

Let's see if 4a95e65 still fails...

Assuming 4a95e65 is still failing - trying out a hunch.

-    $settings['settings']['apcu_ensure_unique_prefix'] = (object) [
-      'value' => FALSE,
-      'required' => TRUE,
-    ];
+    // A hunch
+//    $settings['settings']['apcu_ensure_unique_prefix'] = (object) [
+//      'value' => FALSE,
+//      'required' => TRUE,
+//    ];

Continuing with the bisect

I don't believe this bisect... :(

So according to the bisect...

d1ae9b77ad02e0771206084da1fe6205405a489d is the first bad commit
commit d1ae9b77ad02e0771206084da1fe6205405a489d
Author: Nathaniel Catchpole <catch@35733.no-reply.drupal.org>
Date:   Tue Jun 14 16:23:38 2016 +0100

    Issue #2651102 by mikeker, amateescu, gaurav.pahuja, Sagar Ramgade, dawehner, akalata, catch: Using checkboxes for exposed filters results in zero rows displaying

:040000 040000 8a28e54069fc7fd22b2525932d0c99f0db2898e4 3affb5a6b2a1858aed1a0950a26d079cd6e42f88 M	core

But I'm not sure if this means anything...

Let's see what happens to test run times with unique APCu prefixes.

Let's see if just adding a comment to webtestbase fixes things (for whatever reason)

Here's a proper patch to remove non-unique APCu prefixes just in case we decide to try this as a solution.

In my mind this is fixed - looking at node/3060/qa these have gone away since the commit.