## Problem
Studio still called the legacy `/workers` Management API routes and used
the old `project_worker` response contract, so Compute instances could
not be listed or retrieved after the API rename. The production API type
check also detected drift in the v1 and platform declarations.
## Fix
- Regenerate the v1, v2, and platform API declarations from the deployed
schemas.
- Update Studio list and detail queries to `/compute`.
- Align typed fixtures with the Compute response schemas and
`project_compute_instance` resource type.
- Update platform response type references to the generated `_Output`
schema names.
## How to test
- Run `pnpm api:verify-types`.
- Run `pnpm --filter api-types test`.
- Run `pnpm --filter studio test data/compute/compute.utils.test.ts
"tests/pages/project/[ref]/compute/index.test.tsx"`.
- Run `pnpm --filter studio typecheck`.
- Run `pnpm --filter common typecheck`.
- Run `pnpm --filter studio lint:ratchet`.
Expected result: production API declarations are synchronized, and
Studio requests the `/compute` list and detail endpoints and renders
`project_compute_instance` responses successfully.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* Updated API response handling across profiles, backups, notifications,
integrations, warehouses, access tokens, payments, and other Studio
workflows for more accurate serialized data.
* Compute instance pages and queries now use the compute-specific API
endpoints and response data.
* Improved feature-flag type handling when disabled feature data is
unavailable.
* **Tests**
* Updated automated coverage and fixtures to reflect current compute and
API response formats.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
platform, v1 and v2 have been already completely migrated and introduced
some changes.
Some types have been renamed, some outputs and inputs updated.
## Solution
- Update the API types
- Fix the TS errors
## Update
Taking this over to unblock #50134, which needs the new scoped token
permission ids from the regenerated types.
- Merged `master`.
- Regenerated `api-v2.d.ts` from the production spec. The previous files
came from a local API that exposed a webhook events endpoint production
doesn't have yet. Production has since added standardized 400 error
responses on the v2 organization endpoints. `api-v1.d.ts` and
`platform.d.ts` already matched production.
- Fixed `verify-production-types`. It formatted the regenerated files in
a temp directory outside the repository, so Prettier fell back to its
defaults and the comparison could never match the committed files. It
now passes the repository config explicitly. `pnpm api:verify-types`
passes on this branch.
- Verified locally: `pnpm typecheck`, `pnpm api:verify-types`, Studio
unit tests.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Preserved descriptions when saving, sharing, moving, or unsharing
notebooks, reports, SQL snippets, and saved queries.
* Improved handling of empty or null values across notebook
descriptions, billing usage, pooler settings, and infrastructure fields.
* Improved read-replica connection handling, including read-only
connection strings.
* Updated storage configuration and capability handling to match current
settings.
* **API and Compatibility**
* Updated organization, project, storage, OAuth, billing, and
infrastructure data handling to match current API responses.
* OAuth app creation and updates now require scopes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
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.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## 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.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Jordi Enric