search

nextcloud / updater

:arrows_counterclockwise: The updater app to keep your Nextcloud up-to-date
GNU Affero General Public License v3.0
45 stars 33 forks source link

The step file is getting left around after `finalize()` #566

Open joshtrichards opened 4 months ago

joshtrichards commented 4 months ago

This doesn't look right:

2024-05-25T05:44:01+0000 RnQG5qanp7 [info] POST request for step "12"
2024-05-25T05:44:01+0000 RnQG5qanp7 [info] startStep("12")
2024-05-25T05:44:01+0000 RnQG5qanp7 [info] finalize()
2024-05-25T05:44:01+0000 RnQG5qanp7 [info] storage location: /data/updater-ociz9efdik2y/downloads/nextcloud/
2024-05-25T05:44:01+0000 RnQG5qanp7 [info] call opcache_reset()
2024-05-25T05:44:01+0000 RnQG5qanp7 [info] end of finalize()
2024-05-25T05:44:01+0000 RnQG5qanp7 [info] endStep("12")

finalize() does the cleanup - removing the .step file - then we're also calling endStep("12") again somehow according to our logs. This re-adds a .step file again, stuck in step 12.

First seen while troubleshooting some updater issues on the forum, then reviewed the logs from running tests. Indeed.

joshtrichards commented 4 months ago

I think the only reason this hasn't been a bigger problem is because the Updater (in server) repair steps also clean-up the .step file in most cases.

joshtrichards commented 4 months ago

I guess we should separate out the .step removal from step 12 so it's always the very last thing done. That way we don't have to rely on the repair step.

Admittedly, the repair step should basically always run if the occ upgrade / doUpgrade() completes, but it's odd we're both removing the file in the Updater then immediately (accidentally) recreating it then relying on the post-Updater upgrade to clean up again.

Though the real cause of the issue I was looking into that turned up the above I suspect is: #567