Add ability to make the FE trigger automatic dashboard refresh#6442
Conversation
- extract fetchSuggestions into a separate module to break circular dependency - handle headers not existing in API response (no headers in tests)
|
RobertJoonas
changed the title
| * | ||
| * BE: lib/plausible_web/plugs/internal_stats_api_version.ex | ||
| */ | ||
| export function maybeReloadForApiVersion( |
There was a problem hiding this comment.
issue, blocking: I think this must be unit tested quite extensively.
The FE makes multiple requests for data concurrently. The requests may hit different instances of the BE. During rolling deploys, the BE instances may report different API versions. What should happen?
I suggest we spec it out with a jest test suite that includes the concurrent requests during rolling deploys scenario.
I suspect we may need to set a flag that we're about to update to have deterministic behavior, e.g. at module level, let reloadingDueToApiVersionChange
There was a problem hiding this comment.
During rolling deploys, the BE instances may report different API versions. What should happen?
Uff, yeah good catch! I feel like this is now turning into an infrastructure problem. So basically, a dashboard reload is useless until there's old code still around on at least one app server. We definitely don't want the dashboard to keep reloading itself until our deployment finishes.
I guess the version bump should happen separate from the code change then. I'm now thinking about storing the version in Postgres and bumping it via remote shell once all deployments have finished, maybe?
There was a problem hiding this comment.
I've landed on :rpc.multicall to get the effective API version as the minimum across the cluster, falling back to the current node version on non-cluster setups or when the multicall fails. the "effective version" value is cached for 30s.
Basically, the idea is that when we start rolling out new code, the effective version will be the old one for as long as there's at least one app node still at that version. This guarantees that all nodes have updated once we trigger the automatic refresh.
However, the client can still (re)load the dashboard manually while deployment is in progress, meaning they'd get the new FE code with requests served by the old BE. Although there's a version mismatch there, we don't reload the page because the frontend API version is ahead. Basically the frontend is in the correct state, and just waiting for the backend to update.
|
|
||
| @spec effective_version() :: non_neg_integer() | ||
| def effective_version() do | ||
| GenServer.call(__MODULE__, :get) |
There was a problem hiding this comment.
Although it's highly unlikely this process might go bad or become a bottleneck, I'd consider persisting the effective version in ETS instead and attempting to fetch it here with a graceful fallback, just in case. It could be done in a way similar to Salts https://github.com/plausible/analytics/blob/master/lib/plausible/session/salts.ex#L10-L27
3 participants
Changes
Resurrecting what was started in #5362.
Adds a new plug in the
:internal_stats_apipipeline that adds anx-api-versionresponse header. Incrementing the value will trigger an automatic dashboard refresh.In order to not trigger repeated dashboard reloads during deployments, the
x-api-versionheader gets the value of the minimum version across the cluster. Each node has@api_versioncompiled in. That same value gets passed into the FE via a<meta>tag. Without the meta tag in the DOM, the frontend defaults toEXPECTED_API_VERSION = 0, which:Whenever the FE version gets ahead of the BE (i.e. load the dashboard from a freshly deployed node while some app servers are still on the old version), we do not refresh the dashboard. Done by comparing version integers.
Tests
Changelog
Documentation
Dark mode