Cannot upgrade to this version of the plugin due to existing unprocessed data

[thepurpleblob]

Tried to upgrade on our production site and got the above. Huh?

If there are special requirements for doing to upgrade it should be properly flagged up somewhere and/or it should just deal with them. We, effectively, have a load of grief to deal with now.

EDIT: OK, I finally found this... https://docs.moodle.org/30/en/Plagiarism_Prevention_URKUND_Settings#Installation_failed_due_to_unprocessed_data

I think this is going to catch people out (like me) who haven't seen that documentation update. Either get Urkund to tell people or (even better) figure out a way to deal with the old queue as part of the upgrade. Or something else... but something :)

[danmarsden]

That warning message links directly to a wiki doc that explains it in more detail and describes possible solutions. Did you click on that link? I am happy to consider improvements to that if you have any suggestions.

[thepurpleblob]

I must admit, I didn't see the link (we ran the command line update). To be honest, by the time you get that message on a 30K user production system with people in suits breathing down your neck it caused me to have a bad morning (the "why didn't you test it properly" police). I needed to know about it before I attempted the upgrade. The vast majority where stuck in a '613' error state anyway due to a DDOS attack earlier in the week. Icing on the cake ;-)

[danmarsden]

arg - sounds nasty :-(

any ideas on how we should improve the error/process? - I'm definitely open to changing the way it works - I was just trying to be careful and not allow people to get into a situation where some valid submissions are not submitted to urkund and missed during the upgrade.

[thepurpleblob]

Having slept on this... the most important thing (to me anyway) is that the thing keeps going. Having Urkund submissions down for a period of time is much, much worse than losing a few queued submissions. We can deal with that, but being unexpectedly stuffed was very stressful.

While I appreciate the message, by the time it comes it's too late. I don't know how you communicate this 'gotcha' before the upgrade but it's pretty critical that you (or Urkund) do otherwise I think you will have a lot of unhappy punters ;-)

[danmarsden]

yeah - sorry about the stress! - I can't think of a cleaner way to communicate the info during the code upgrade, I guess I was hoping that people might notice it during a test upgrade using their production data before they upgrade their live site and see it there if it was likely to be a problem for them but I can imagine it could be pretty stressful hitting it for the first time during a production upgrade. I'll see if I can test this during a CLI upgrade to see if there's anything we can do to improve the warning messages that appear when it fails on CLI. But let me know if you have any other suggestions.

[thepurpleblob]

If you think about it... it's highly unlikely that a lightly loaded test site will show this up. It's only on a production system with hundreds of submissions floating by that you are likely to have a few (or lots even) sitting in the queue.

[danmarsden]

yeah - good point - I'm in fantasy land thinking that people will test using a current copy of their current production data before running the live upgrade... I don't know the last time I did that myself with a minor plugin upgrade.

[danmarsden]

I'm not sure what you're asking there. I was working on new code - asked for other people to help with testing - Howard upgraded a production site before the code was released in the moodle.org plugins db.

I did perform a lot of testing.... I then asked if there were others that could help before I updated the plugins entry with the latest code. I am greatly appreciative of the support that Howard and others provided.

[thepurpleblob]

It's cool... I appreciate that this sort of software is incredibly difficult to test thoroughly without taking a deep breath and running on a production site. On the whole it works great, there are just a few edge conditions we need to iron out.

[danmarsden]

Cool - any thoughts on how to deal with the existing unprocessed data any differently from the way the upgrade currently works? - The code is obviously operating "as per design" but I understand how stressful it would be to see on a production upgrade (particularly CLI) - the web-based upgrade should be pretty clear about next-steps.

[thepurpleblob]

TBH... I'd be perfectly happy to have lost the unprocessed data and just carried on. A few unprocessed submissions we can work around but the Urkund detection being stopped I cannot

[danmarsden]

Thanks - I'll flick URKUND an e-mail about it and get them to make the call.

[danmarsden]

FYI - URKUND decided they wanted this check left in place. - I've also included more information about the potential error on the main page of the plugins db entry.