1287851 - Investigate if/why background update checks aren't happening during first session after an update

Status: RESOLVED INVALID

(Toolkit :: Application Update, defect)

Description

[Stephen A Pohl [:spohl]]

Attachment: console-log.txt

The pastebins in bug 1277925 comment 28 seem to indicate that we fail to run background update checks during the first session after an update. We should investigate if this is truly the case and if yes, fix it. Attached is one of the pastebins (both pastebins in bug 1277925 are equivalent for the purpose of this bug).

Comment 1

[Robert Strong (they/them - no direct email)]

The next background update check notification should occur 24 hours after the previous background update check notification whether an update was applied or not. This can probably be verified with the existing telemetry.

Comment 2

[Stephen A Pohl [:spohl]]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1)
> The next background update check notification should occur 24 hours after
> the previous background update check notification whether an update was
> applied or not. This can probably be verified with the existing telemetry.

I would argue that this should be changed to an immediate check. Is there a good reason to wait for 24 hours? Especially with watershed releases we probably want users to detect the latest version as quickly as possible.

Comment 3

[Robert Strong (they/them - no direct email)]

That argument would just as well apply to all background update checks and not just during the first session after an update check. In other words, someone that just performed an update check and a watershed release was advertised. There is no data to show that 24 hours after the previous background update check isn't already more than adequate and for this case if it isn't then either shortening the interval if the servers can handle it or using a push notification (this is currently being investigated I believe by go faster) would be the better solution.

Comment 4

[Stephen A Pohl [:spohl]]

You misunderstood. This is asking for background update checks to run immediately after an *update* has occurred, not an *update check*.

Comment 5

[Robert Strong (they/them - no direct email)]

I understood that was what you are asking. I am saying that adding the additional code for this one case doesn't handle cases that are almost exactly the same and that if this is an issue that is worth fixing then the other issue that I stated is just as much worth fixing. Please re-read comment #3.

Comment 6

[Stephen A Pohl [:spohl]]

I would think that simply clearing the lastUpdateCheck pref when an update occurred would not add much complexity and we could improve the speed at which users detect the latest update (in case of watershed releases) or confirm that they're now running the latest version. Do you disagree?

Comment 7

[Robert Strong (they/them - no direct email)]

I am saying that if this is an issue then people that have just performed a background update check just prior to a watershed release is also an issue.

I suspect that there are many more systems that fall into the group for the similar issue I stated above. I say this because we disable updates to the latest version when we are planning a watershed release.

When we push out updates unthrottled this would cause all clients to perform an additional update check. This would definitely increase the load on the aus server significantly.

There is no data at this point that shows this would be valuable. If there is then fixing this for both cases (e.g. an update has just been applied and a background check has just been performed) could be done by shortening the interval that background checks are performed or by using a push notification.

Comment 8

[Stephen A Pohl [:spohl]]

Fair enough, thanks for the explanation!