## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Minor update for long running state thresholds when updating project
sizes
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Increased the minimum threshold for recognizing long-running
operations from 10 to 20 minutes, reducing premature fallback behavior
and improving stability for longer tasks.
* **Tests**
* Updated test suite to validate the new 20-minute threshold across
default, missing, small, and larger restore scenarios.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
Bug fix / UX improvement for long-running project transitions. Resolves
DEPR-362.
## What is the current behaviour?
- `PausingState` does not preserve elapsed time across refreshes, so the
stuck escalation can disappear for the same user.
- `RestoringState` relies on weaker frontend heuristics and always
showed a support CTA in the footer even before the restore was clearly
long-running.
## What is the new behaviour?
- `PausingState`
- Persists a per-project pause start time in local storage so the stuck
CTA survives refreshes in the same browser.
- Escalates after 10 minutes.
- Clears the stored timer when pausing succeeds or fails.
- `RestoringState`
- Persists a per-project restore start time in local storage so the
stuck CTA survives refreshes in the same browser.
- Removes the always-visible footer CTA and only escalates once
restoration is genuinely long-running.
- Computes the long-running threshold from volume size using a shared
restore estimate: `max(10, ceil(estimateRestoreTime(sizeGb) * 1.5))`.
- Clears the stored timer when restoration succeeds or fails.
- Shared changes
- Extracts reusable transition timing helpers and restore estimate
helpers with unit tests.
- Reuses the same restore estimate formula for branch restore timing and
restore escalation, so the two do not drift.
| `PausingState` | `RestoringState` |
| --- | --- |
| <img width="1570" height="906" alt="Krosno Toolshed
Supabase-C6D7E29F-C38D-43E1-8AF9-C612B6A2FD8D"
src="https://github.com/user-attachments/assets/e0bd9434-09b6-4cf6-bffa-07a0ddcdf5db"
/> | <img width="1570" height="906" alt="Krosno Toolshed
Supabase-51F4763D-B798-4B41-A92D-43B3CF8ECDAF"
src="https://github.com/user-attachments/assets/d0e47356-dcc3-42aa-b602-802a35249a16"
/> |
## Additional context
- This PR intentionally stays frontend-only.
- We are not exposing backend lifecycle timestamps here; local storage
is the stopgap to improve the same-browser experience now.
- If you need to test the frontend blocker states locally, use
[`dnywh/chore/depr-362-blocker-preview-mocks`](https://github.com/supabase/supabase/tree/dnywh/chore/depr-362-blocker-preview-mocks)
and append one of the following query params to a project URL:
- `?mockProjectBlockingState=pausing`
- `?mockProjectBlockingState=pausing-long-running`
- `?mockProjectBlockingState=restoring`
- `?mockProjectBlockingState=restoring-long-running`
- I know these two views are quite differently stylistically, and will
consolidate later
- References DEPR-434
Ali Waseem