fix(dashboard): invalidate project caches after environment mutations (#657) - #690
Closed
Rish-it wants to merge 2 commits into
Closed
fix(dashboard): invalidate project caches after environment mutations (#657)#690Rish-it wants to merge 2 commits into
Rish-it wants to merge 2 commits into
Conversation
createEnvironment patched the environments list from the dedicated endpoint but left infoCache holding the old bundle — the next projectInfo emit re-ran the seeding effect and wrote the stale list back over the fresh patch, so the new environment vanished until a reload. Invalidate the current id plus its known siblings first: the list ships inside every environment's /info payload, so sibling bundles go stale too. refreshEnvironments() stays as the immediate correct patch; the invalidation-triggered /info refetch is stale-while-revalidate, so no mounted page flashes empty.
…n#657) handleDeleteProject doubles as the environment delete (the server tears down THIS environment and only soft-deletes the app row once its last one is gone) but navigated home on success without invalidating anything, leaving the dead entry in every sibling's cached switcher. All three success exits now drop the known ids — the two inside try and the 404 in catch, where another tab already deleted the row so this tab's bundles are guaranteed stale. Real failures (409 active-work, deletion-in-progress, teardown-failed) keep every cache as-is. The eviction cost for unmounted siblings is pure cache-drop — no request storm, just a slower first paint on next visit.
Member
|
already fixed sorry |
Contributor
Author
|
my bad Thanks !! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #657
Problem
Adding a new environment didn't update the UI until a hard refresh, and a deleted environment lingered in every switcher the same way.
Root cause
Two writers into one
environmentsstate:ProjectSettingsContext.tsxre-seeds the list from the bundled/infopayload wheneverprojectInfochangesrefreshEnvironments()patches it from the dedicated list endpointcreateEnvironmentonly patched the second, so the module-levelinfoCachekept the stale bundle — the nextprojectInfoemit wrote the old list back over the fresh patch. Delete went throughhandleDeleteProject(which doubles as the environment delete — the server tears down THIS environment and only soft-deletes the app row once its last one is gone) with no invalidation at all, and it navigates home on success, so the dead entry survived in every sibling's cached bundle.The list ships inside EVERY environment's
/infopayload, so sibling caches go stale on any mutation — invalidating only the current id would leave the bug one click away.Fix
Two commits, each self-consistent green:
400b52c2) —createEnvironmentcallsinvalidateProjectCaches(id)before returning, then also invalidates known sibling ids.refreshEnvironments()stays as the immediate correct patch.67671ef2) — all three success exits ofhandleDeleteProjectinvalidate: full ok, unrecoverable-partial, and the cross-tab 404 in catch, where another tab already deleted the row so this tab's bundles are guaranteed stale. Real failures (409 active-work, deletion-in-progress, teardown-failed) keep caches as-is.Reuses the existing tool for this exact situation (
useProjectEndpoints.ts— "Drop ALL caches for an id AND notify subscribed hooks to refetch"), already used by AdvancedSettings, RoutingUnsyncedCallout and useDeploymentBuild.No flash risk: same-id refetches are stale-while-revalidate (
beginFetchStatekeeps what's on screen), and eviction of unmounted siblings is pure cache-drop — no request storm.Test plan
project-settings-environments.test.tspins the wiring in source (same no-jsdom idiom asadvanced-migration-session.test.ts): create-path invalidation + ordering, sibling coverage, helper definition, ≥3 success exits, 404 orderingvitest run: 1058/1058 passed (×2 clean runs)tsc --noEmit: clean (×2)