Significantly reduce the check interval for review request page updates.

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

Information

Review Board
release-6.x

Reviewers

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
indefinitely.

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
frontend.

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
server-side.

Python and JavaScript unit tests pass.

Summary ID
Significantly reduce the check interval for review request page updates.
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 indefinitely. 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 frontend. 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.
e4c8f7ee47f71e700fe3f788d30421c539899fe5
david
  1. Ship It!
  2. 
      
chipx86
Review request changed
Status:
Completed
Change Summary:
Pushed to release-6.x (5014207)