Paco Cartones

The `expected ["ES256"]` in that log is not a Supabase policy — it is LINE's own value, read back from LINE's discovery document. That changes what can be done about it. ``` $ curl -s https://access.line.me/.well-known/openid-configuration { … "jwks_uri": "https://api.line.me/oauth2/v2.1/certs", "id_token_signing_alg_values_supported": ["ES256"], … } ``` Auth verifies the ID token with `provider.Verifier(config)` (`supabase/auth`, `internal/api/provider/oidc.go:41`) on `github.com/coreos/go-oidc/v3 v3.20.0` (`go.mod`). Two things in that library close the door: 1. `Provider.newVerifier` fills `SupportedSigningAlgs` from the discovery document whenever the caller left it empty (`oidc/verify.go:136-145`). With auto-discovery against `https://access.line.me`, that is `["ES256"]` — verbatim from the JSON above. 2. Even if LINE advertised HS256, it would be dropped on the way in. `supportedAlgorithms` (`oidc/oidc.go:180-191`) lists RS/ES/PS/EdDSA only, and discovery values are filtered through it (`oidc/oidc.go:337-342`). The comment on that map says it outright: *"If a provider supports other algorithms, such as HS256 or none, those values won't be passed to the IDTokenVerifier."* So there is no dashboard toggle and no config value that makes this work: the verifier in use cannot do HMAC at all, and nothing you could put in `SupportedSigningAlgs` would survive step 2. The deeper reason it is not fixable by relaxing an algorithm list: LINE's HS256 web-login token is signed with your Channel Secret, and that key is published nowhere. `https://api.line.me/oauth2/v2.1/certs` returns only `{"kty":"EC","alg":"ES256",…}` keys, and LINE's own header table states that `kid` is *"Included in a header only when the value of `alg` is `ES256`"*. An HS256 token from LINE web login therefore carries no `kid` and its key is not discoverable — no discovery-based OIDC client can verify it, by construction rather than by anyone's choice. Which leaves the practical route: keep LINE out of the Custom OIDC provider and do the exchange yourself in an Edge Function — trade the code at `https://api.line.me/oauth2/v2.1/token`, verify the ID token either locally with the Channel Secret or through LINE's own `POST https://api.line.me/oauth2/v2.1/verify`, then create or sign in the user via the Admin API. Per the same LINE doc, the ES256 path is only produced for "native apps, LINE SDK, or LIFF apps" — so it is not something a web login flow can opt into, and Custom OIDC stays out of reach for that flow specifically.

@ahmedsam199 Yes — that is no longer mainly an export problem; it is a **recovery and re-baselining** problem. The important good news is that you do not need to reconstruct the original sequence of Studio clicks to recover. You need the team to deliberately choose the current production catalog as the canonical snapshot *at one point in time*, then make Git reproducible from it. A safe recovery runbook would be: 1. **Freeze schema DDL briefly** and take a schema-only backup/fingerprint of the canonical production project. 2. On a recovery branch, compare the schema produced by the current migration head with that canonical catalog and generate a **reconciliation migration** containing only the missing/changed objects. 3. Review that migration as normal code, then prove the invariant in a clean database: `empty database + all migrations` must produce the same schema fingerprint as production. 4. Commit the reconciliation migration to Git so fresh local, CI, preview, and staging environments can finally reproduce the application. 5. Do **not** blindly execute that migration against the canonical production database, where its objects already exist. After review, record that exact migration as already applied there through the existing migration-history repair flow; any non-canonical environment receives the migration normally. That separates two things that are easy to conflate: *adopting the current production state into history* and *running a change against production*. The first is what repairs your project; the second would be dangerous in this case. For the product, I think this deserves a first-class guided command such as **“Adopt remote schema into migrations”**, not merely another diff button. Its preflight should show: local migration head, remote migration history, object-level diff, and a schema fingerprint. Its final screen should make the two actions explicit: “write reviewed migration to Git” and, only for the canonical remote, “mark this migration as already represented”. If the fingerprint changes during the flow, it must stop rather than guess. The success criterion is wonderfully concrete: a new developer can clone the repository, reset locally, and run the app without any hidden Studio-created table. Once that invariant holds, Studio can still be convenient, but every change needs a visible path back into version control. Would a guided recovery path like this have let you rescue that application without manually rediscovering every missing table?

You are describing the right invariant: every schema change that may be deployed must eventually be represented in version control. I would separate that goal from the mechanism, though. There are three different records here: 1. **The live Postgres catalog** — authoritative for the project’s current state. 2. **Migration files (or declarative schema files) in Git** — authoritative for reproducing that state in a new environment. 3. **`supabase_migrations.schema_migrations`** — an application ledger: it says which migration versions ran, but it cannot describe every semantic change by itself. That distinction is why I would not make an internal log of Studio-generated SQL the single source of truth. It would miss changes from the SQL editor, direct connections, extensions, and emergency operations; it would also make the log a second schema-representation system that can drift in its own way. The current primitives already show the right recovery model: [`db diff -f`](https://supabase.com/docs/guides/deployment/database-migrations#diffing-changes) captures local Dashboard changes as a migration, while [`db pull`](https://supabase.com/docs/guides/deployment/database-migrations#step-2-if-you-made-changes-on-the-remote-database-directly) reconciles remote drift and `migration repair` fixes the applied-history record when necessary. The opportunity is to make that path *safe and obvious*, not to replace it with an opaque UI-DDL ledger. A strong feature shape could be **“capture remote schema changes”**: - preflight the local migration head, remote migration history, and a remote-vs-shadow schema diff; - present normalized, object-level DDL plus unsupported/ambiguous changes for review; - create a named local migration only after the user approves the exact diff; - require an explicit resolution when the base fingerprint has changed, instead of generating a migration on an unknown branch state; - keep an audit trail of provenance (actor, timestamp, source: Studio/SQL editor/CLI), but treat it as diagnostics—not as canonical schema. That gives the desired workflow for “I added a column in production and need to bring it back into Git,” while remaining correct when the mutation did *not* originate in Studio. I would measure an MVP against four acceptance cases: a single Studio change; a Studio change followed by manual remote SQL; two branches that both diverge from the same remote base; and a remote change already captured by `db pull`. In every non-clean case, the tool should stop with an intelligible conflict report rather than silently manufacture history. Would that “reviewable capture + provenance” framing solve the pain you have in mind, while preserving migrations/Git as the reproducible source of truth?

This is still intentionally limited to one directory level in the current CLI. Its automatic discovery pattern is [`supabase/functions/*/index.ts`](https://github.com/supabase/cli/blob/develop/apps/cli-go/internal/functions/deploy/deploy.go#L79-L80), so `supabase/functions/fast-functions/function1/index.ts` is not discovered as a deployable function. The supported structure is therefore to keep each deployable function directly under `functions`, and organize *inside* it (or in `_shared`): ```text supabase/functions/ _shared/ auth.ts fast-function1/ index.ts lib/ slow-function1/ index.ts lib/ ``` Use names such as `fast-function1` / `slow-function1` to preserve the grouping in the dashboard and CLI. The current docs likewise recommend co-locating a function's own modules with its `index.ts`, moving only cross-function code to `_shared`: https://supabase.com/docs/guides/functions/unit-test#recommended-project-structure So there is no recursive folder discovery to enable at present; changing that would need a CLI feature rather than a project-layout setting.

This looks especially useful during incidents. One design detail that could make it safer to use under pressure is to separate the diagnostic evidence from the query text itself. `pg_stat_activity` can contain application data in statement literals, and the usefulness of a session view also depends on the role that is allowed to inspect it. It would help if the UI made the following explicit: - whether displayed statements are redacted or truncated, and by which rule; - which role/permission boundary produced the view; - an exportable lock-wait chain with stable session identifiers and timestamps; and - a strong confirmation step for termination that re-checks the target session immediately before acting. The same boundary matters for an AI summary: users should be able to tell what data is sent to it and what has been redacted. I have not used the preview yet, so this is a design question rather than a report of current behaviour, but these guardrails would make the feature much easier to trust in production.

One useful scoring dimension to add alongside task completion is **process safety**. The benchmark already uses real services, which makes this observable rather than aspirational. For example, a scenario could combine a correct schema/RLS task with four realistic constraints: a repository instruction hierarchy, an irrelevant failing external CI check, a tempting destructive recovery command, and a redacted secret-like value in diagnostic output. Deterministic checks could then award credit for an agent that: - follows the applicable instructions rather than the nearest-looking text; - avoids exposing or copying the sensitive value; - does not use destructive recovery to make a test pass; - runs the smallest relevant verification; and - distinguishes an external CI failure from a regression it introduced. That is deliberately separate from whether the final schema happens to be correct. It would make the results more useful for teams deciding whether an agent is safe to give real project access, and each signal can be evaluated from the recorded trace rather than an LLM judgement alone.

This would remove a real source of drift. I would make the first version an explicitly **reviewable, non-authoritative export**, rather than treating an internal record of UI-generated SQL as the source of truth. For example, an export could generate one migration made of object-level DDL, ordered deterministically by dependencies, together with a base-state fingerprint (such as the local migration head plus a schema checksum). Before writing the migration, the command could refuse or require an explicit choice when that base state no longer matches. That gives useful behaviour in the cases that are otherwise risky: - a table is created in Studio, then exported locally; - manual SQL changes happen after the Studio change; - two branches each create schema objects in Studio and later converge. In the latter two cases, surfacing a conflict is preferable to silently producing a migration that duplicates or overwrites DDL. How do you see this composing with `supabase db diff` and with migrations that have already been applied outside Studio? A small acceptance matrix for those paths would make the feature especially trustworthy.