Test failing on 8.x-2.x on 10.0.x and 10.1.x

Tests are passing on 9.5.x, so clarifying.

• For the 10.1 failures, see commit fb6d0d7f5ae3ca612a93b755716c23de4c15acd2 for #3314137: Make Automatic Updates Drupal 10-compatible.
• For the 10.0.5 failure: I bet that this is due to 10.0.5 itself being insecure (10.0.8 is a security release). That in turn means that the test is NOT actually testing a mocked core version. I previously discovered this >3 months ago and reported it: #3337049: Assert no errors after creating the test project in ModuleUpdateTest.

Based on the red test runs on 10.0.5 and the green ones after 88a29e25 - fix from 3320792 (that message is misleading, because it's actually a fix copied from the MR at #3337049! 😅🙈) I think we can conclude that #3337049: Assert no errors after creating the test project in ModuleUpdateTest is a must-have now, for both the 8.x-3.x branch (that issue) and 8.x-2.x (this issue).

https://git.drupalcode.org/project/automatic_updates/-/merge_requests/86... is not the solution I suggested in #6 😅

I referred to https://git.drupalcode.org/project/automatic_updates/-/merge_requests/52....

Why that commit?

Because the test failure you're seeing on this issue for 10.1 has this output:

Problem 1
    - composer/composer 2.5.5 requires symfony/polyfill-php81 ^1.24 -> could not be found in any version, there may be a typo in the package name.

and that commit contains:

        // If we're running on Drupal 10, which requires PHP 8.1 or later, this
        // polyfill won't be installed, so make sure it's not required.
        if (str_starts_with(\Drupal::VERSION, '10.')) {
          unset($package['require']['symfony/polyfill-php80']);
        }

… but turns out that that is already present in the 8.x-2.x branch too…

Notice how the only difference is symfony/polyfill-php80 vs symfony/polyfill-php81? Let's apply the same pattern for 10.1 and that new version :)

Where is this mockActiveCoreVersion()? It's not in the MR.

The remaining failure is

1) Drupal\Tests\automatic_updates\Functional\UpdatePathTest::testUpdatePath
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
 Array &0 (
-    'status_check_timestamp' => 1666285089
+    'status_check_last_run' => Array &1 (
…
+    )
+    'status_check_timestamp' => 1683624980
 )

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:122
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79
/var/www/html/modules/contrib/automatic_updates/tests/src/Functional/UpdatePathTest.php:77
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

Line 77 of that test.

These are lines 70 through 77:

    // TRICKY: we do expect `readiness_validation_last_run` to have been renamed
    // to `status_check_last_run`, but then
    // automatic_updates_post_update_create_status_check_mail_config() should
    // cause that to be erased.
    // @see automatic_updates_post_update_create_status_check_mail_config()
    // @see \Drupal\automatic_updates\EventSubscriber\ConfigSubscriber::onConfigSave()
    unset($expected_values['status_check_last_run']);
    $this->assertSame($expected_values, $key_value->getMultiple(array_values($map)));

So we see that a key-value pair for the key status_check_last_run exists, despite it NOT being expected.

So what is setting it? When is that happening? The comments on lines 70–75 provide helpful pointers and have commit/issue history associated with them.

Please follow the breadcrumbs. This is also what @tedbow, @phenaproxima or I would need to do!

Almost there!

Now this just needs to pass the code quality checks 😊 As soon as those pass too, this is RTBC!

@yash.rode @Wim Leers thanks for working on this. Good to get the 8.x-2.x tests passing again!