skills/supabase__supabase
1
0
Fork 0
mirror of https://github.com/supabase/supabase.git synced 2026-09-22 13:37:53 +08:00
Code Issues Packages Projects Releases Wiki Activity
38,659 Commits 1,712 Branches 0 Tags
docs/cli-deploy-next-step
Commit Graph

7 Commits

Author SHA1 Message Date
Alaister Young 29493e02d0 [FE-4010] feat(studio): add read-only replica connection option for HA projects (#49485) 
For Multigres (HA) projects you can't connect to read replicas directly
— reads go through a read-only load balancer on the primary's host at
port 5433. Since #44695 stripped the pooler UI, HA projects showed no
source option at all in the Connect dialog and still prompted for the
IPv4 add-on. This surfaces it as a first-class, clearly-labeled
read-only source. In the UI it's labeled `Replica (read-only)` rather
than "load balancer" — the primary goes through the same gateway, so
"load balancer" would be confusing from a product perspective
(internally the `load-balancer` source identifier and
`HIGH_AVAILABILITY_LOAD_BALANCER_PORT` constant keep their names).

<img width="883" height="342" alt="Screenshot 2026-08-24 at 11 32 26 PM"
src="https://github.com/user-attachments/assets/3716f6dd-0325-4b9d-adbc-9ece9244de62"
/>

**Added:**
- Source select for HA projects in the Direct tab: `Primary database` +
`Replica (read-only)` (individual replica rows are filtered out —
they're only reachable via the load balancer)
- Replica (load balancer) connection strings on all 9 connection types:
primary host, port `5433`, with the Multigres-required
`sslmode=require&sslnegotiation=direct` params (JDBC gets the
`sslNegotiation` spelling, .NET gets `SSL Negotiation=Direct`)
- `Read-only` badge on the connection code block + note pointing writes
at the primary
- Programmatic labels for the ConnectSheet select/switch/multi-select
fields (the Source combobox previously had no accessible name)

**Changed:**
- The generated-file step (Node.js/Golang/.NET/Python/SQLAlchemy) is now
source-aware — it previously ignored the Source selection entirely (also
affected read replicas on normal projects) and silently rendered the
primary's connection info
- .NET template now emits `Port=` (Npgsql defaults to 5432 when omitted)
and the install step actually installs Npgsql (pinned 9.0.5 — `SSL
Negotiation` requires 9+)
- SQLAlchemy `DATABASE_URL` merges `sslmode=require` into the string's
existing query params instead of a hardcoded suffix that could drop TLS
- Source option labels normalized to sentence case (`Primary database`,
`Read replica (…)`)
- `MultipleCodeBlock` (ui-patterns) accepts an optional `className`
- HA coercion in `useConnectState` extended: a stale replica
`connectionSource` restored from URL/localStorage falls back to the
primary

**Removed:**
- IPv4 add-on admonition for HA projects (the forced-direct method was
tripping it; the add-on doesn't apply to Multigres)

Out of scope (needs platform work): SQL editor / Data API / other
`DatabaseSelector` surfaces — executing against the load balancer
requires a platform-issued connection string, and the load-balancers API
only returns a REST endpoint today. The `5433` port is a client-side
constant (`HIGH_AVAILABILITY_LOAD_BALANCER_PORT`) until the API exposes
it.

## To test

On an HA (Multigres) project:
- Open Connect → Direct: Source shows exactly `Primary database` and
`Replica (read-only)`; selecting the replica shows
`…@<primary-host>:5433/postgres?sslmode=require&sslnegotiation=direct`,
a `Read-only` badge, and the read-only note
- Cycle all 9 connection types with the replica selected — every snippet
carries port 5433 (`.NET` includes `Port=5433;…;SSL
Negotiation=Direct`), badge/note persist
- No "Enable IPv4 add-on" admonition anywhere in the Direct tab
- Switch tabs / hard-reload: source resets to primary with no stale
badge/string combos

On a normal project:
- Direct tab unchanged: no `Replica (read-only)` option, pooler badges
and IPv4 admonitions behave as before, `.NET` now shows `Port=5432` and
no `SSL Negotiation`

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Added read-only load-balancer connection options for high-availability
projects.
- Added .NET and SQLAlchemy connection examples with required SSL
settings.
- Added clear read-only labels and notices explaining write
restrictions.
- **Bug Fixes**
  - Suppressed IPv4 add-on notices for high-availability connections.
  - Improved connection-source selection and restored-setting handling.
  - Improved connection form identification and accessibility.
- **Style**
  - Added customizable styling support for multi-code-block displays.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
 2026-08-28 10:43:55 +01:00
Alaister Young fc5e03f9e3 [FE-4019] fix(studio): direct-only connection strings with SSL params for Multigres (#48433) 
Multigres (high-availability) projects only accept TLS connections with
direct SSL negotiation, and they don't support connection pooling at all
— neither Supavisor nor the dedicated PgBouncer pooler exists for them.
Studio previously showed pooler connection strings that would fail with
"server closed the connection unexpectedly". This PR makes every
connection-string surface direct-only for HA projects and appends
`?sslmode=require&sslnegotiation=direct` to the examples. Non-HA
projects are unchanged.

Addresses
[FE-4019](https://linear.app/supabase/issue/FE-4019/append-ssl-params-to-multigres-connection-string-examples-in-ui)

**Changed:**

- `buildConnectionStringPooler` gets an HA branch that collapses every
slot in the bag to the direct connection string with the SSL params
appended (mirroring the existing CLI branch, which also has no pooler) —
dedicated slots come back `undefined` and
`ipv4SupportedForDedicatedPooler` is forced off. Since HA never reaches
the pooler layout anymore, the earlier per-URI SSL-append logic on
pooler strings is removed
- `useConnectState` coerces `connectionMethod` to `direct` and
`useSharedPooler` to `false` for HA projects. The Connect sheet restores
the last-used method from localStorage shared across projects, so a
"Transaction pooler" selection made on a regular project could otherwise
leak pooler-flavored notices, badges, and telemetry into an HA project
- Prisma and Drizzle ORM tabs get an HA branch:
`DATABASE_URL`/`DIRECT_URL` both use the direct connection, no
`?pgbouncer=true` appended, with a comment explaining Multigres doesn't
support pooling. The 5-arm nested ternaries in both files are flattened
into `getEnvCode` helpers that switch on a shared
`resolveOrmConnectionScenario` helper (`OrmConnection.utils.ts`), so the
deployment-mode/HA branching lives in one tested place and each file
keeps only its own formatting
- The PgBouncer and Supavisor config queries are disabled (`enabled:
!isHighAvailability`) in the Connect sheet — those endpoints serve
pooler config that doesn't exist on Multigres
- `parseConnectionParams` keeps the URI's query string in a new `search`
field so formats rebuilt from parsed parts can carry it
- psql switches from the `-h/-p/-d/-U` flag form to the quoted-URI form
when query params are present (flags can't express them; psql still
prompts for the password)
- JDBC appends the params using pgJDBC's casing (`sslNegotiation`,
supported since 42.7.4)
- Prisma's `?pgbouncer=true` appends are query-aware (join with `&` when
the URI already has a query string) via a new
`appendConnectionStringParams` helper
- The project home "Direct connection string" copy item also appends the
params for HA projects

**Added:**

- Unit tests for the HA collapse behavior (all slots direct, dedicated
config and IPv4 add-on ignored, no SSL params on non-HA output), the
`useConnectState` coercion, the psql/JDBC builders (moved from
`content.tsx` into `ConnectionString.utils.ts` so they're testable), and
`resolveOrmConnectionScenario` (every deployment-mode/HA/pooler branch)

**Known gaps (left out deliberately):**

- The grid ExportDialog psql/pg_dump commands, the .NET
`appsettings.json` (Npgsql only supports direct negotiation from v9 via
`SSL Negotiation=Direct`), and the SQLAlchemy keyword-style `.env` are
flag/keyword forms that can't carry the URI params — these would still
fail against Multigres and need a follow-up
- Settings > Database's Connection Pooling section and the pooler logs
page have no HA gating yet — they'd still render pooler config UI for a
Multigres project and should be hidden in a follow-up

## To test

On a **Multigres (HA) project** (staging only supports `us-east-1` for
Multigres):

- Open the Connect sheet → Direct tab: there's no connection-method
picker, and the connection string is the direct one ending with
`?sslmode=require&sslnegotiation=direct` for the URI, PHP, and psql
(quoted-URI form) types; JDBC includes
`&sslmode=require&sslNegotiation=direct`
- ORM tab → Prisma: both `DATABASE_URL` and `DIRECT_URL` are the direct
connection string with the SSL params, no `pgbouncer=true`, with a
"Multigres does not support connection pooling" comment. Drizzle
likewise shows the direct string only
- Framework tabs (e.g. Next.js): every `DATABASE_URL` carries the direct
string with the params exactly once
- Open the network tab: no requests to `/config/pgbouncer` or
`/config/supavisor` while using the Connect sheet
- To check the localStorage coercion: on a **regular** project pick
"Transaction pooler" in the Connect sheet, then open the sheet on the
Multigres project — no pooler badge/notices, string is still direct
- Copy the URI, substitute your password, and `psql "<string>"` — it
should connect
- Project home → Copy dropdown → "Direct connection string" includes the
params

On a **regular (non-Multigres) project** — confirm nothing changed:

- Connect sheet: direct/session/transaction strings for all connection
types (URI, psql flag form, JDBC, PHP) look the same as before, no SSL
params appended
- Prisma/Drizzle tabs render identically (`?pgbouncer=true` still
appended with `?`, dedicated-pooler alternatives still shown per IPv4
add-on state)
- Project home copy dropdown is unchanged


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Enhanced connection-string generation for high-availability projects,
including required SSL settings for direct connections.
* Preserved URI query parameters in PostgreSQL, `psql`, JDBC, and
generated environment configurations.
* Improved ORM environment templates with clearer handling for pooler
and high-availability connection scenarios.

* **Bug Fixes**
* High-availability projects now consistently use direct connections
instead of pooler options.
* Connection strings and generated templates update correctly when
availability settings change.

* **Tests**
* Expanded coverage for query parameters, high-availability behavior,
and connection scenarios.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
 2026-07-31 14:34:31 +08:00
Saxon Fletcher d8fadcc1c8 makes it possible to reset password from connect dialog (#46866) 
Makes it possible to reset password from the connect sheet. Once reset
the password is shown temporarily in the connection string for copy. The
copy prompt action does not copy the password.

<img width="1043" height="953" alt="image"
src="https://github.com/user-attachments/assets/fe1a33bb-839f-47e3-b07f-7a5fa1df2b8d"
/>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
  * Session Pooler notice for direct connections on IPv4 networks
* Option to show a temporary database password during direct-connection
setup

* **Improvements**
  * New password reset dialog with strength checks and generation
* Connection-copy behavior now redacts temporary passwords and produces
cleaner copy prompts

* **Tests**
* Added tests covering connection-string password insertion/replacement
and copy-prompt behavior
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-06-12 07:38:18 -06:00
Andrey A. c1b473e472 fix: adjust connect sheet for cli and self-hosted (#46217) 2026-05-25 15:13:25 +02:00
Charis 4a0bb36ca8 style: require sorted imports in studio/components (#44408) 
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
 2026-04-01 10:22:37 +02:00
Ali Waseem 8a26132bde fix(studio): resolve outstanding Sentry issues (#44106) 
## Summary

Fixes several high-impact Sentry errors reported in production.

### Fixed Issues

- **[SUPABASE-APP-EJ3](https://supabase.sentry.io/issues/7356937474/)**
— `TypeError: Cannot read properties of undefined (reading 'direct')`.
`connectionStringPooler` could be `undefined` when the connection source
doesn't match any key in the connection strings map. Added an early
return guard in `resolveConnectionString`.

- **[SUPABASE-APP-B17](https://supabase.sentry.io/issues/7117468199/)**
— `RangeError: Invalid time zone specified: Etc/Unknown`.
`dayjs.tz.guess()` returns `"Etc/Unknown"` for some users with
misconfigured browser/OS timezones. Added a shared
`guessLocalTimezone()` helper that validates the guessed timezone via
`Intl.DateTimeFormat` and falls back to UTC. Applied across all 4 call
sites.

- **[SUPABASE-APP-BCM](https://supabase.sentry.io/issues/7192934901/)**
— `TypeError: Cannot convert undefined or null to object`.
`Object.entries(definition.properties)` crashed when a JSON schema
definition existed but had no `properties` field. Updated the guard to
check `definition?.properties` instead of just `definition`.
- https://supabase.sentry.io/issues/7357780302/?project=5459134
- https://supabase.sentry.io/issues/7358344652/?project=5459134
- https://supabase.sentry.io/issues/7096737077/?project=5459134

## Test plan

- [ ] Verify connect dialog renders without errors when connection data
is still loading
- [ ] Verify API docs Entity view handles schema definitions without
properties
- [ ] Verify charts/tooltips display correct timezone labels

---------

Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
 2026-03-23 21:20:47 +00:00
Saxon Fletcher b9a09d8612 Connect sheet content structure (#42373) 
This is part two of a [PR
breakdown](https://github.com/supabase/supabase/pull/42276) that
introduces our connect schema and how content is retrieved. This focuses
on the Framework tab to start.

Fields are generated and content is rendered using a connect.schema
file. This schema file defines modes, fields and steps. Each mode has a
set of fields. Each field can be dependent on another field. The steps
generated are then based off the values of the modes and fields. Each
step can also render varying content dynamically using a template
{{framework}}/{{frameworkVariant}}/{{library}} which just replaces those
values with what's in state (fields selected).

[Part one needs to be merged
first.](https://github.com/supabase/supabase/pull/42367)

The next stage will add back all other tabs and content.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* New Connect Sheet UI to guide app-to-project connections with dynamic
configuration and copyable connection parameters.
* Multi-framework & mobile support with ready-to-use code examples,
install commands, and step-by-step setup for 20+ frameworks.
* Multiple PostgreSQL connection methods (direct, transaction, session)
with safe/masked connection previews.
  * Copy-prompt that aggregates step content and code for easy sharing.
* **UI**
* Multi-file code viewer with tabbed code blocks and added syntax
support (Swift, TOML, HTML).
* **Tests**
  * Comprehensive unit tests for resolver and state logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-02-11 13:32:45 +08:00