should be able to request cancellation of staged (bad) update
Categories
(Toolkit :: Application Update, task, P3)
Tracking
()
People
(Reporter: aryx, Unassigned)
References
Details
(Whiteboard: [fidedi-ope])
Bug 1750188 was about an issue with https connections broken in Nightly which also prevented Nighly from updating with the affected version installed.
The affected update was available only for a short time window (10-30 minutes for Windows), Nightly updates had been halted and new Nightly builds with the issue resolved got built and were available ~4h later.
If we discover an issue, it would be reduce the impact of a bad update if staged updates for it (= Firefox is running and has download the update to it but hasn't been restarted and applied it yet, e.g. if the machine is running unattended or doesn't get launched and closed often) could be canceled. Pushing this request via remote settings sounds preferable to the a response from the update server (app.update.interval checks every 12 hours in release, app.update.background.interval every 7 hours).
|
Reporter | |
Comment 1•3 years ago
|
||
Amir, could this get onto the updater roadmap to reduce the impact of issues with updates in the future?
|
||
Comment 2•3 years ago
|
||
I'm not sure that I understand the problem or the change that you are looking for. Could you help me understand?
It sounds to me like there was an update that was correct in that it was signed and distributed properly, but it had a serious enough bug that, after distribution, we wanted to be able to "retract" it so that it would only ever be applied by people that restarted before it was retracted. Does that sound about right?
Could you tell me a little bit about how remote settings work such that they are a better fit for this? Do they have some sort of push capability? Or perhaps they just update more often? Or do we need to check the remote setting manually at some point in the update process?
It seems to me that we will want to have this be a bit more targeted than just deleting every staged/downloaded update everywhere. Could the remote setting communicate, say, the bad build ID? Inevitably, some people will be really out of date and will have downloaded a complete update that is older than the bad update. It doesn't seem like we should delete their update.
|
|
Reporter | |
Comment 3•3 years ago
|
||
(In reply to Kirk Steuber (he/him) [:bytesized] from comment #2)
It sounds to me like there was an update that was correct in that it was signed and distributed properly, but it had a serious enough bug that, after distribution, we wanted to be able to "retract" it so that it would only ever be applied by people that restarted before it was retracted. Does that sound about right?
Exactly.
Could you tell me a little bit about how remote settings work such that they are a better fit for this? Do they have some sort of push capability? Or perhaps they just update more often? Or do we need to check the remote setting manually at some point in the update process?
Last week during the incidence in bug 1749910 / bug 1749957 it was mentioned remote settings has a push capability and is able to reach all active/registered clients within a few minutes.
It seems to me that we will want to have this be a bit more targeted than just deleting every staged/downloaded update everywhere. Could the remote setting communicate, say, the bad build ID? Inevitably, some people will be really out of date and will have downloaded a complete update that is older than the bad update. It doesn't seem like we should delete their update.
Yes, the service/server should send the message "If version X staged as update, drop the staged updated". In general, updates in general will be halted, hence "and update to the next better version available" hasn't been added (this requires adding new update rules which require sign off).
Added Michael as the remote settings owner.
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Comment 4•3 years ago
•
|
||
[:aryx] we have added this into our team roadmap
|
|
Reporter | |
Comment 5•3 years ago
|
||
Thank you, the information has been added to the action items of foxstuck document.
|
|
||
Comment 6•3 years ago
|
||
Setting P3. This is on our roadmap, but not for the next two cycles. There are a couple of things ahead of it.
Description
•