XF 2.2 Unable to resume/restart UserAvatar200 job that crashed after upgrade from 1.5 to 2.2

[Jake B.]

The avatar resize job failed because of a disk read issue that has been resolved. The upgrade state completed as if it were properly complete, but avatars didn't work. However, there doesn't appear to be a way for me to run it again or resume it

 

[Jake B.]

Added this CLI command to trigger it temporarily:

<?php

namespace XF\Cli\Command\Rebuild;

class RebuildAvatars extends AbstractRebuildCommand
{
    protected function getRebuildName()
    {
        return 'avatars';
    }

    protected function getRebuildDescription()
    {
        return 'Runs the avatar upgrade step.';
    }

    protected function getRebuildClass()
    {
        return 'XF:Upgrade\UserAvatar200';
    }
}

Seems to be working, but won't know for certain until it's complete

 

[Chris D]

Honestly, in an ideal world, the solution we'd have recommended would have been to restore a backup and do the upgrade again from scratch. I don't think it would be worth the effort allowing the job to be re-run (which is almost certainly a job we don't want people to be able to run more than once).

Of course I respect that restoring from a backup is far from optimal.

FWIW I'd have probably recommended simply just adding the job directly to the xf_job table with a trigger_date of 0 but I don't envisage the approach you took would cause any issues.

INSERT INTO `22x`.`xf_job` (`unique_key`, `execute_class`, `execute_data`, `manual_execute`, `trigger_date`) VALUES ('upgradeUserAvatarRebuild200', 'XF:Upgrade\\\\UserAvatar200', 'a:0:{}', 0, 0);

 

[Jake B.]

Honestly, in an ideal world, the solution we'd have recommended would have been to restore a backup and do the upgrade again from scratch.

Yeah, had thought about it since it was only a first run through on a test upgrade but the upgrade took around 7 hours to complete, and their NFS mount seems a bit finnicky so I wouldn't be too surprised if it crashes again and I have to resume it (which I hope will work with the --resume flag on the rebuild base CLI command, but at the same time hope I don't have to find out if this is the case )

I don't think it would be worth the effort allowing the job to be re-run (which is almost certainly a job we don't want people to be able to run more than once).

That was my thought as well, the CLI command I added is going to be removed as soon as we do the live upgrade so it doesn't get run by mistake.

FWIW I'd have probably recommended simply just adding the job directly to the xf_job table with a trigger_date of 0 but I don't envisage the approach you took would cause any issues.

thought about that as well, but wanted it in a state that I could run it and see progress on CLI. From my (limited) understanding, if I queued it in xf_job manually it'd get triggered either when a user calls job.php, or when the cron triggers the xf:run-job CLI command if it's setup. Seemed like the cleanest short-term fix with the least impact.

Not sure how feasible it'd be, but if that crashes being able to run xf:upgrade again and having it resume that job would be nice and probably the least impactful. I tried that initially, but it only prompted to rebuild master data since XF assumed it was fully upgraded

 

[Chris D]

You can run individual upgrade steps and I may have recommended that.

The command to do that would be:

xf-dev:upgrade-step 2000010 53

But in this case I don't think it's a great idea as that particular step (Version2000010::step53()) inserts a number of other jobs and runs a number of other queries that may not have been ideal.

None of the upgrade process nor the upgrade steps are designed to be run twice so we can't say for certainty whether adverse effects can happen by doing that. I suspect this one would be ok, but if you only need to re-run this then your approach or the xf_job approach is probably better.

 

[Jake B.]

If it crashes again I'll at least have the user ID it failed on so I'm sure I can find some workaround to get it to resume from that spot without too much issue. I don't suspect it'll come to that though as so far it's running through smoothly, just a lot of users it needs to process (Currently at around 800k/12m users - not sure how many of these actually have avatars though)