Significantly reduce the check interval for review request page updates.

Review Request #13297 — Created Oct. 1, 2023 and submitted — Latest diff uploaded


Review Board


When checking for updates, we were polling every 10 seconds. Aside from
CI builds, most results are returned much faster than that, and often
would result in an e-mail going out with the review before the page even
got its update.

This change reduces the time from 10 seconds to 2, which is going to be
a better experience in most cases.

The polling interval has exponential backoff applied, with a multiplier
of 1.15, and a cap of 10 seconds. For very long-running checks, like CI
builds, this will be more reasonable, and will avoid swamping the server

To do this, a bug/unutilized feature in the backend was addressed. We
had a mechanism for filtering updates by timestamp, and this wasn't
being used by the frontend at all. A recent change introduced a
timestamp that could be used by the backend, with filtering done on the

The server-side filtering would have been ideal, but was broken due to
trying to compare timestamps with microseconds to timestamps without.
That has now been fixed, with issue summary table timestamp comparisons
being added to the backend. This allows us to remove the front-end
tracking of per-entry timestamps, add a max "last timestamp" variable,
and use that to rely on the ?since= parameter.

Tested with extensive log output and checking both the client-side
and server-side output. Verified that the polls started at 2 seconds
and then backed off over time.

Tested that the timestamp calculations server-side with ?since=
is now working correctly.

Tested that empty payloads were no longer causing crashes (which only
now happens because timestamp calculations are fixed).

Tested that no updates came in without making changes to the timestamp

Python and JavaScript unit tests pass.