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: 📌 Assert no errors after creating the test project in ModuleUpdateTest Needs review .

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 📌 Assert no errors after creating the test project in ModuleUpdateTest Needs review is a must-have now, for both the 8.x-3.x branch (that issue) and 8.x-2.x (this issue).

tests for 10.0.5 are passing now but for the fix recommended in #6 🐛 Test failing on 8.x-2.x on 10.0.x and 10.1.x Fixed for 10.1 was already part of the upstream and it is not able to fix the test failures on Drupal 10.1.

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 :)

I think the test failure is because, we are not mocking the core version which we did in this? but I am not sure if this is the actual problem and I tried using mockActiveCoreVersion() to set the core version but it's not able to find the 'update_test.settings' schema.

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!

#3314137-20: Make Automatic Updates Drupal 10-compatible → is mind blowing, trying to catch up with it.

As discussed in https://www.drupal.org/project/automatic_updates/issues/3314137#comment-... →
for 10.1 now it works same as it used to work for 9.5 I tried locally and step 4. which triggers automatic_updates_modules_installed() is happening now for 10.1 also, so I think we should be re-rolling the fix for this test.

https://www.drupal.org/project/automatic_updates/issues/3358878#comment-... 🐛 Test failing on 8.x-2.x on 10.0.x and 10.1.x Fixed is causing the failure in 10.0.5 and 9.5.

Discussed this in the meet just now and we(@phenaproxima and @tedbow) have decided to add a workaround for now as 8.x-2.x is not maintained. doing that in the next commit.

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

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