Problem/Motivation

In #3365490: [DrupalCon] Automatic Updates alpha test result @UpTil4Music ran into a problem after the update was applied and end up back at the UpdateReady form

The received this messages

Your site does not pass some readiness checks for automatic updates. It cannot be automatically updated until further action is performed.
Some modules have database schema updates to install. You should run the database update script immediately.
Problem detected in lock file during stage operations.
Unexpected changes were detected in composer.lock, which indicates that other Composer operations were performed since this Package Manager operation started. This can put the code base into an unreliable state and therefore is not allowed.

Basically something went wrong and the stage was not deleted.

but in any case the composer.lock is not very helpful.

This comes from \Drupal\package_manager\Validator\LockFileValidator::validate

// If we have both hashes, ensure they match.
    if ($active_hash && $stored_hash && !hash_equals($stored_hash, $active_hash)) {
      $messages[] = $this->t('Unexpected changes were detected in composer.lock, which indicates that other Composer operations were performed since this Package Manager operation started. This can put the code base into an unreliable state and therefore is not allowed.');
    }

We originally wrote this validator to ensure no other operations where happening on the active site between when you started the process and when you applied the changes.

Steps to reproduce

Proposed resolution

In \Drupal\package_manager\Validator\LockFileValidator::validate inside

if ($active_hash && $stored_hash && !hash_equals($stored_hash, $active_hash)) {
.....
    }

Before giving the current messages check if the active hash is actually equal to the staged hash. This would indicate that staged operation has already been applied.

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

tedbow created an issue. See original summary.

tedbow’s picture

Issue summary: View changes

tedbow’s picture

Issue tags: +Needs tests, +core-post-mvp, +sprint
tedbow’s picture

Issue tags: +Usability
tedbow’s picture

Issue tags: +Pittsburgh2023
phenaproxima’s picture

Here's another approach that might be simpler: how about we delete the stored hash earlier, during post-apply?

Right now we do it doing post-destroy, but really, there's no reason to keep the stored hash once the changes are applied.

tedbow’s picture

Status: Active » Needs work

#8 that seems like a good idea. But I still think we keep the changes in MR 912 because even though in #3365490: [DrupalCon] Automatic Updates alpha test result it was because something went wrong before delete it easily could have been because something went wrong before postApply. So I think MR 918 lower the chances of this happening I don't think it eliminates.

omkar.podey made their first commit to this issue’s fork.

omkar.podey’s picture

Assigned: Unassigned » omkar.podey
phenaproxima’s picture

Title: Improve messaging if the staged update has already been applied » [PP-1] Improve messaging if the staged update has already been applied
Status: Postponed (maintainer needs more info) » Postponed