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
Issue fork automatic_updates-3366289
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
Comment #3
tedbowComment #5
tedbowComment #6
tedbowComment #7
tedbowComment #8
phenaproximaHere'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.
Comment #10
tedbow#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.
Comment #12
omkar.podey commentedComment #13
omkar.podey commentedblocked on changes in #3357969: For web server dependent unattended updates run the entire life cycle in a separate process that will not be affected by hosting time limits
Comment #14
phenaproxima