First test fails on postgres because of a stale connection

I think that test is run, and it passed on DrupalCI. The order of test results is not guaranteed because of concurrency > 1.

09:30:47 Drupal\aggregator\Tests\FeedValidationTest                    12 passes                                      
09:30:48 Drupal\system\Tests\Action\ActionUnitTest                     15 passes                                      
09:30:48 Drupal\aggregator\Tests\Views\AggregatorFeedViewsFieldAccess  15 passes                                      
09:30:48 Drupal\aggregator\Tests\Views\AggregatorItemViewsFieldAccess  20 passes                                      
09:30:52 Drupal\aggregator\Tests\Views\IntegrationTest                 38 passes                                      

I ran this test all by itself and it fails:

https://dispatcher.drupalci.org/job/DCI_XML/100/

This isn't an issue with drupalci - they do fail if its the first test. The issue is that there is a totally random order to run-tests.sh every time.

This test just happens to pass when some other test has already paved the database way for it.

This isn't an issue with drupalci - they do fail if its the first test. The issue is that there is a totally random order to run-tests.sh every time.

But then why did the test never run in https://dispatcher.drupalci.org/job/default/12472/consoleFull (per @alexpott)? That would point at a problem in test discovery.

Edit: Or is the idea that the test did actually run and that comment was erroneous? It does actually seem to be listed on that page.

+++ b/core/modules/simpletest/src/KernelTestBase.php
@@ -193,6 +193,20 @@ protected function setUp() {
     }
     $this->kernel->boot();
 
+    // Ensure database tasks have been run.
+    require_once __DIR__ . '/../../../includes/install.inc';
+    $connection = Database::getConnection();
+    $errors = db_installer_object($connection->driver())->runTasks();
+    if (!empty($errors)) {
+      $this->fail('Failed to run installer database tasks: ' . implode(', ', $errors));
+    }
+
+    // After running the database tasks we have to reboot the container so that
+    // a new database connection is created.
+    $this->kernel->shutdown();
+    $this->kernel->boot();

This feels potentially fragile. Can't we call $connection->close(); $connection = Database::getConnection() or something like that?

@alexpott: to be fair, Drupal\aggregator\Tests\Views\AggregatorItemViewsFieldAccessTest is too long to show up in run-tests.sh default columnar output, so it gets cut off at Drupal\aggregator\Tests\Views\AggregatorItemViewsFieldAccess. Truncated output achievement unlocked.

I manually tested this (updated the STR) and the patch fixes the issue. Given how tests are run in our infrastructure, it's not possible to provide a reliably failing test for this, so manual testing should be enough.

+++ b/core/modules/simpletest/src/KernelTestBase.php
@@ -193,6 +193,22 @@ protected function setUp() {
+    // After running the database tasks we have to reboot the container so that

It still IMHO doesn't explain exactly why we need a new database connection (because the tasks potentially close them?)

Previous patch is green, this is just a doc change, so no need to wait for the bot :)

Updated issue summary with beta evaluation template.

Committed/pushed to 8.0.x, thanks!

Sad to report that this seems not completely fixed. Over in #2426579: Change method name for pgsql driver's ensureIdentifiersLength() to accurately describe what the method is doing the first test was failing during one of the PG bot runs :(
Please see: https://www.drupal.org/pift-ci-job/31911

We had hacked in a 62 second wait (used to be 5) hoping that would be enough. Will add this to our 'to look at list'

Ah yes, thanks! And I just discovered #2564659: pgsql does not always turn on where @isntall already committed a first patch, let's see :)