Disables network bans for v3 (`AWS_K8S`) projects and shows a specific
unsupported notice. The shared banned-IP query waits for project details
and skips unsupported projects, covering both Database Settings and
Advisor for v3 and High Availability projects.
The hook returns the standard query result and uses `skipToken` to
prevent unsupported requests, including manual refetches. Database
Settings handles project-detail errors at the call site. Open unban
confirmations are cleared when the section becomes disabled, and
submission checks eligibility.
Addresses
[FE-4483](https://linear.app/supabase/issue/FE-4483/disable-network-bans-for-v3-aws-k8s-projects).
## To test
- Open Database Settings on a v3 project. Check that Network bans shows
the v3 notice, hides the IP list and unban controls, and makes no
network-bans retrieval request on initial load or reload, including
while Advisor is mounted.
- Check that an HA project still shows its existing notice and makes no
network-bans retrieval request on initial load or reload.
- Navigate from a supported project to a v3 or HA project and check that
no banned-IP request is sent for the unsupported project and no
banned-IP signals from the previous project appear in Advisor.
- If project details fail without cached data, check that Network bans
shows an error after retries finish and does not retrieve bans. A
successful retry should restore normal behavior.
- Open an unban confirmation on a supported project, then navigate to a
v3 or HA project. Check that the dialog closes without sending an unban
request and stays closed when returning. A newly opened confirmation
should still work.
- On a supported project, check the empty state and banned IP list.
Confirm that users with permission can unban an IP and users without
permission see a disabled button with the permissions tooltip.
Validation: 17 focused tests passed, covering automatic and manual
request suppression, project-detail error display and recovery, and
navigation between supported and unsupported projects. Changed-file
ESLint, Prettier, and full Studio typecheck (without the incremental
cache) passed. Earlier local browser checks on `9912c6c` confirmed no
retrieval requests for an HA project on AWS_K8S across reloads and
Advisor, and a successful empty state on a supported project. The local
failed-project case redirected to the organization after retries, so the
inline error remains verified by the component test only. The latest
preview, standalone v3 notice, populated bans/unban, and no-permission
tooltip still need browser verification.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Banned IP settings now show an unsupported-project notice for AWS
Kubernetes projects and hide ban lists and unban actions for AWS
Kubernetes and High Availability projects.
* Banned IP data loads only after project details are available and only
for supported projects; unsupported projects do not display cached ban
data.
* Project-detail errors are shown separately from ban-list errors.
* Unban confirmations close when a project becomes unsupported or an
unban succeeds. Unbanning is unavailable when you lack update permission
or the project is unsupported.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## What kind of change does this PR introduce?
Feature. Resolves DEPR-430.
## What is the current behaviour?
The homepage Advisor summary, shared Advisor panel, and top-nav Advisor
indicator only surface lints and notifications. Banned IPs are not
represented as dismissible Advisor items, so network bans are easy to
miss unless a user visits Database Settings directly.
The `public bucket allows listing` warning is no longer part of this PR.
That warning will move to a follow-up Splinter `WARN` lint so it can
flow through the standard lint surfaces instead of a bespoke Studio
signal path.
## What is the new behaviour?
- adds a new Advisor `signal` source for banned IPs on the platform
homepage, in the shared Advisor panel, and in the top-nav Advisor
indicator
- keeps dismissals client-side only for now, scoped by project and exact
IP fingerprint
- keeps banned IP signals at `warning` severity because they still
indicate suspicious traffic and remain actionable if a user wants to
review or remove a ban
- leaves `/project/[ref]/advisors/security` as follow-up work because
that surface is still lint-native, and banned IPs are management-plane
signals rather than Splinter lints
| After |
| --- |
| <img width="1728" height="997" alt="Mallet Toolshed
Supabase-65A60B4A-107E-4D79-B9A8-23F754BEAB08"
src="https://github.com/user-attachments/assets/c08ecbbb-c302-43bd-81bb-6ba7eb18b7b3"
/> |
## Reviewer testing notes
1. Use a throwaway project.
2. Get the database connection string for that project.
3. Attempt to connect with the wrong password 3-4 times until you hit an
`ECONNREFUSED`-style error, which should mean your IP has been banned.
4. Refresh Studio and confirm the project overview shows the new `Banned
IP address` signal.
5. Open the Advisor Center and confirm:
- the top-nav Advisor dot turns warning yellow
- the signal detail shows `Entity`, `Issue`, and `Resolve`
- `Edit network bans`, `Dismiss`, and `Learn more` are present
6. Open Database Settings > Network bans and confirm your banned IP
appears there and can be unbanned.
7. Note that `/project/[ref]/advisors/security` will not show this item.
That page is still lint-only, and this banned IP work is a short-term
client-side signal rather than a true lint.
Longer term, we likely want a more durable event model here so banned
IPs can power notifications, webhooks, emails, and other project-level
alerts.
---------
Co-authored-by: kemal <hello@kemal.earth>
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* Add custom types for queries, mutations and infinite queries.
* Migrate all queries to use the new type.
* Migrate all infinite queries to useCustomInfiniteQueryOptions.
* Migrate all mutations to use useCustomMutationOptions.
* Add type to all imports in `types` folder.
* Migrate all uses of invalidateQueries to use object syntax.
* Migrate the remainder of useInfiniteQuery.
* Migrate all setQueriesData.
* Migrate all fetchQuery uses.
* Migrate some leftover functions from RQ.
* Fix issues found by Charis.
* Update the design of the sonner toasts. Add the close button by default.
* Migrate studio and www apps to use the SonnerToaster.
* Migrate all toasts from studio.
* Migrate all leftover toasts in studio.
* Add a new toast component with progress. Use it in studio.
* Migrate the design-system app.
* Refactor the consent toast to use sonner.
* Switch docs to use the new sonner toasts.
* Remove toast examples from the design-system app.
* Remove all toast-related components and old code.
* Fix the progress bar in the toast progress component. Also make the bottom components vertically centered.
* Fix the width of the toast progress.
* Use text-foreground-lighter instead of muted for ToastProgress text
* Rename ToastProgress to SonnerProgress.
* Shorten the text in sonner progress.
* Use the correct classes for the close button. Add a const var for the default toast duration. Remove the custom width class from sonner.
* Set the position for all progress toasts to bottom right. Set the duration for all toasts to the default (when reusing a toast id from loading/progress toast, the duration is set to infinity).
* Fix the playwright tests.
* Refactor imports to use ui instead of @ui.
* Change all imports of react-hot-toast with sonner. These components were merged since the last commit to this branch.
* Remove react-hot-toast lib.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Co-authored-by: Jonathan Summers-Muir <MildTomato@users.noreply.github.com>
* First round of wrapping RQ errors with handleError
* Remove the throw before the handleError usage.
* Make the handling of an API error more versatile. Add logging in Sentry if the error is of unknown type.
* Remove throwing of the handleError function.
* Add return type to the handleError function to be never so that we're sure it always throws.
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* chore: increase react-query stale time
* keep staleTime: 0 for table rows
* use staleTime: 0 for all user sql queries
* use staleTime: 0 for all pg-meta queries
* Some fixes
* fix updating tables
* fix bug while editing column names
* Fix deleting column in database/tables column list not revalidating UI
* Fix updating column in database/tables column list throwing ane rror
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* Move all studio files from /studio to /apps/studio.
* Move studio specific prettier ignores.
* Fix the ui references from studio.
* Fix the css imports.
* Fix all package.json issues.
* Fix the prettier setup for the studio app.
* Add .turbo folder to prettierignore.
* Fix the github workflows.
