fix: ensure signing out cannot cause any runtime render errors #13137
Conversation
| <ErrorBoundary> | ||
| <AppProviders> | ||
| <RouterProvider router={router} /> | ||
| </ErrorBoundary> | ||
| </AppProviders> | ||
| </AppProviders> | ||
| </ErrorBoundary> |
There was a problem hiding this comment.
Important – before, if any of the sub-components in AppProviders threw an error, we had nothing to catch it. Moved ErrorBoundary to be the top-most component
| const obj = JSON.parse(rawContent as string); | ||
| if ("regions" in obj) { | ||
| return obj.regions as Region[]; | ||
| } | ||
| return obj as Region[]; |
There was a problem hiding this comment.
@Emyrk I wasn't completely sure why we had a check for whether the data getting parsed was either an array or an object with the array inside it, but just to be on the safe side, I ripped this out and centralized it in the metadata manager file
There was a problem hiding this comment.
Great question. The type safety we have on these fields is terrible, and should be resolved imo to make things like this more clear. We just inject strings that are json. Very weak imo.
I'll dig a bit and find out
| metadata: metadata.regions, | ||
| queryKey: ["get-proxies"], | ||
| queryFn: async (): Promise<readonly Region[]> => { | ||
| const endpoint = permissions.editWorkspaceProxies | ||
| ? getWorkspaceProxies | ||
| : getWorkspaceProxyRegions; | ||
| const resp = await endpoint(); | ||
| return resp.regions; | ||
| }, |
There was a problem hiding this comment.
Just inlined a bunch of the values, since they're only used here
| /** | ||
| * 2024-05-02 - If we persist any form of user data after the user logs | ||
| * out, that will continue to seed the React Query cache, creating | ||
| * "impossible" states where we'll have data we're not supposed to have. | ||
| * | ||
| * This has caused issues where logging out will instantly throw a | ||
| * completely uncaught runtime rendering error. Worse yet, the error only | ||
| * exists when serving the site from the Go backend (the JS environment | ||
| * has zero issues because it doesn't have access to the metadata). These | ||
| * errors can only be caught with E2E tests. | ||
| * | ||
| * Deleting the user data will mean that all future requests have to take | ||
| * a full roundtrip, but this still felt like the best way to ensure that | ||
| * manually logging out doesn't blow the entire app up. | ||
| */ | ||
| defaultMetadataManager.clearMetadataByKey("user"); |
There was a problem hiding this comment.
This is the main part of the fix
| const isHomePage = location.pathname === "/"; | ||
| const navigateTo = isHomePage | ||
| ? "/login" | ||
| : embedRedirect(`${location.pathname}${location.search}`); | ||
|
|
There was a problem hiding this comment.
Moved the variables here because they're only relevant for this block
| const experimentsKey = ["experiments"] as const; | ||
|
|
||
| export const experiments = (): UseQueryOptions<Experiments> => { | ||
| export const experiments = (metadata: MetadataState<Experiments>) => { |
There was a problem hiding this comment.
I do want to go back and add explicit return types, but I was on a tight deadline, and didn't have time to figure it out
These functions are still type-safe and will let you know if you wire things wrong. They're just not "add explicit type parameter"-safe, because of TypeScript type parameter shenanigans
Parkreiner
changed the title
Parkreiner
changed the title
|
I found this fix quite complex but comprehensible 👍 good job. I also tested it locally. |
Closes #13130
Changes made
Notes
useMetadataQueryhook to improve the ergonomics of wiring up our metadata to React Query, but this is a decent first step towards that