You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We ever so often see users running into the following problem: they have their Airbyte webapp opened in the browser for very long time. We update the backend during that time. When they now try to navigate and load a JS/CSS chunk they haven't loaded beforehand this chunk no longer exists on the server, and loading the chunk will just fail, which usually just causes weird errors in the UI. We should show a toast notification to the user if the backend got updated and they need to refresh the page.
For that we could leverage the already existing v1/health call. This could return as part of it's response a custom hash for that server version, and we compare it against the one the frontend code still knows. If they differ show a toast notification asking to refrsh the page.
Why not send the version as part of the response. Sending out versions that the server is, is usually flagged during SOC2 audits as giving out too much information about the system. While we anyway have the version already in the FE, this would kind of not add any new information, but we should still try to not that route so we can later remove versions altogether from the (cloud) product. Any uniquely generated hash would be enough.
The text was updated successfully, but these errors were encountered:
We ever so often see users running into the following problem: they have their Airbyte webapp opened in the browser for very long time. We update the backend during that time. When they now try to navigate and load a JS/CSS chunk they haven't loaded beforehand this chunk no longer exists on the server, and loading the chunk will just fail, which usually just causes weird errors in the UI. We should show a toast notification to the user if the backend got updated and they need to refresh the page.
For that we could leverage the already existing
v1/health
call. This could return as part of it's response a custom hash for that server version, and we compare it against the one the frontend code still knows. If they differ show a toast notification asking to refrsh the page.Why not send the version as part of the response. Sending out versions that the server is, is usually flagged during SOC2 audits as giving out too much information about the system. While we anyway have the version already in the FE, this would kind of not add any new information, but we should still try to not that route so we can later remove versions altogether from the (cloud) product. Any uniquely generated hash would be enough.
The text was updated successfully, but these errors were encountered: