From b6abae6abe089c43f95b8192d1c3f42ef6eed4b9 Mon Sep 17 00:00:00 2001 From: Ali Waseem Date: Wed, 19 Aug 2026 07:51:56 -0600 Subject: [PATCH] fix(studio): only show restore completion once the restore has run (#48948) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Resolves [FE-4144](https://linear.app/supabase/issue/FE-4144/restore-flow-shows-completion-before-restore-is-actually-done) ## Problem `RestoringState` treated any `ACTIVE_HEALTHY` reading from the project status endpoint as "restore finished". Right after a restore is triggered the backend still reports the pre-restore status, so the first poll could land on `ACTIVE_HEALTHY` and flip the UI to "Restoration complete!" seconds into a restore that had barely started. `isCompleted` was local state nothing reset and polling stopped on that first reading, so the screen never self-corrected — "Return to project" then hung until a manual refresh. ## Changes - Gate completion on having observed the project leave the healthy state, so a stale pre-restore reading is no longer mistaken for a finished restore. - Keep polling through an unconfirmed healthy reading instead of stopping on it. - `onConfirm` clears its loading flag rather than relying on the layout to unmount the component. - Component tests covering both the premature completion and the stuck button. ## Needs validation Not yet verified against a real restore — please confirm on staging before merging. Worth checking in particular that a restore which completes normally still reaches the completion screen. There is one residual edge case left in place deliberately: if the details endpoint reports `RESTORING` while the status endpoint reports `ACTIVE_HEALTHY`, the UI now stays on "Restoration in progress" until the details query catches up. Fixing that properly needs an authoritative "restore initiated at" timestamp from the API, which does not exist today. ## Summary by CodeRabbit - **Bug Fixes** - Improved project restoration tracking to prevent completion from being reported prematurely. - Restoration now correctly detects failures and stops polling when appropriate. - Restore status and saved transition information are cleared after successful completion or failure. - Confirmation actions now remain reliable while project details refresh. - Restoring controls become usable again after the process finishes. - Improved the restore menu trigger behavior for more consistent interaction. --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> --- .../ProjectLayout/RestoreFailedState.tsx | 2 +- .../ProjectLayout/RestoringState.test.tsx | 178 ++++++++++++++++++ .../layouts/ProjectLayout/RestoringState.tsx | 64 ++++--- 3 files changed, 218 insertions(+), 26 deletions(-) create mode 100644 apps/studio/components/layouts/ProjectLayout/RestoringState.test.tsx diff --git a/apps/studio/components/layouts/ProjectLayout/RestoreFailedState.tsx b/apps/studio/components/layouts/ProjectLayout/RestoreFailedState.tsx index 2855c96f40a..ade2b7c85b0 100644 --- a/apps/studio/components/layouts/ProjectLayout/RestoreFailedState.tsx +++ b/apps/studio/components/layouts/ProjectLayout/RestoreFailedState.tsx @@ -120,7 +120,7 @@ export const RestoreFailedState = () => { - +