Add ability to make the FE trigger automatic dashboard refresh#6442
Add ability to make the FE trigger automatic dashboard refresh#6442RobertJoonas wants to merge 14 commits into
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.
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 refresh. The version string is defined in the plug itself, and the same value is also passed into the FE via a<meta>tag. Without the meta tag in the DOM, the frontend defaults toEXPECTED_API_VERSION = 0, which:Tests
Changelog
Documentation
Dark mode