DEV Community: Aman Gupta

typescript-eslint suggests void. With supabase-js, that drops the request.

Aman Gupta — Tue, 20 Oct 2026 11:18:29 +0000

For the first 39 sends of a new feature in a production app I run, open tracking just didn't work. The sends went out fine. The opens never got recorded: 39 sends recorded zero opens. No exception, nothing in the logs, every test green. It came down to one word.

The call looked roughly like this (names changed):

void supabase.rpc('track_event', { id });

That void was a habit. typescript-eslint's no-floating-promises complains about promises you don't await, and its message tells you to await it, handle it, or have it "explicitly marked as ignored with the void operator". The first suggestion it offers is "Add void operator to ignore." For an eager promise, like a storage upload or an auth call, that's fine, because the request is already on its way.

A supabase-js query builder isn't like that. It's a lazy thenable, and nothing gets sent until something calls .then() on it. await does that for you. void doesn't. So void supabase.rpc(...) builds the request and then throws it away.

It gets worse. Since typescript-eslint 8.0.0, no-floating-promises doesn't check thenables by default, so a builder you forgot on its own line isn't flagged by anything. And if you turn checkThenables on to catch those, the rule flags every builder and suggests void first, which is the one fix guaranteed to make sure the request never happens.

So I built an ESLint plugin that knows the difference: eslint-plugin-supabase. It has five rules, each for a Supabase mistake that's easy to ship without noticing. Four of them don't produce an error at all.

1. The query that never gets sent

supabase/no-unsent-query flags a lazy builder that's voided or just left sitting there as a statement:

void supabase.from('todos').insert({ title }); // voided: never sent
supabase.from('todos').update({ done: true }).eq('id', id); // never awaited: never sent

You get two suggestions, await (inside an async function) and .then(). There's no autofix, because both change when the request runs, and that's your call to make. .then() chains, await, return and passing the builder somewhere else are all fine. Storage downloads are lazy too, so they're covered.

2. The subscription that never fires

supabase
  .channel('room')
  .on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'messages' }, onMessage)
  .subscribe((status) => console.log(status));

If public.messages isn't in the supabase_realtime publication, this channel happily reaches SUBSCRIBED and then never gets a single event. The only error is a system message your subscribe callback never sees. That same app had a subscription like this sitting on an unpublished table while the table took 1,926 writes. It fired zero times.

supabase/realtime-table-published replays your migrations and reports the subscription, along with the fix: alter publication supabase_realtime add table public.messages;.

3. The read that comes back empty

const { data, error } = await supabase.from('orders').select('*');
// data: [], error: null

If public.orders has row level security on and no select policy for the role your client uses, this read gives you an empty result and no error. An update or delete in the same situation quietly changes nothing, also without an error. (Inserts and upserts fail loudly with 42501, so the rule doesn't bother with them.)

supabase/rls-readable reads your policies from the migrations and reports the read, plus filtered updates and deletes.

4. The channel error nobody hears

supabase.channel('room').on('broadcast', { event: 'ping' }, onPing).subscribe();

Call .subscribe() without a status callback and CHANNEL_ERROR and TIMED_OUT go nowhere. supabase/subscribe-status-handler asks you to pass one: .subscribe((status, err) => { ... }). If you already wrap subscribe in a helper that checks the status, add it to allowWrappers.

5. The call the 2026-10-30 change will break

This one comes with a date, so it gets its own section further down.

Why a linter needs your schema

Supabase's own database linter already catches something close to the empty read (the third one above): lint 0008_rls_enabled_no_policy flags every table with row level security on and no policy. But plenty of those tables are like that on purpose. The app only reads them through a function, and "no policy" is the design.

You can't tell a deliberate table from a broken one by looking at the database alone. You can't tell from the client code alone either: supabase.from('orders').select() looks fine until you know what the migrations say about orders. You need both. So the schema rules replay supabase/migrations into a model of the database (tables, grants, row level security, policies, publication membership) and check every client call against it. A table that's only read through a function never trips rls-readable, because there's no direct client call to report.

The plugin also works out which role each client acts as. A client created with a publishable or anon key is anon or authenticated. A client created with the service role key bypasses row level security, so rls-readable leaves it alone. When the plugin can't trace a client at all, it skips the call and counts the skip. When it can trace the client but can't tell what kind of key it got (createClient(url, config.key)), it treats it like a publishable client by default (unknownKey: "default"), because in client code that's almost always what it is. Set unknownKey: "skip" if you'd rather skip those calls.

2026-10-30: find the call sites before the change does

Supabase has announced that from 2026-10-30, new tables, views and sequences in public stop getting automatic grants for anon, authenticated and service_role on every existing project. A migration that creates a table and forgets the grant will apply cleanly, row level security will look right, and the first request will fail.

After the change, a client call on a new table that the role has no grant for fails with 42501. supabase-grants-lint catches it at the migration. This plugin catches it at the line of client code that will break. A Realtime subscription on such a table fails silently instead: it connects and never receives any data.

supabase/table-granted knows which privileges each call needs (an upsert needs insert, update and select; a filtered delete needs delete and select) and reports a call when no role the client can act as has them:

authenticated has no insert privilege on `public.orders` in your migrations, so this call fails with
42501 (permission denied). Fix in a migration: `grant insert on public.orders to authenticated;`

Right now, before the change, the replayed defaults still grant almost everything, so this rule is quiet on most projects. And the replay doesn't look at the calendar. It only sees the change once your project records it, either with the opt-in migration (the revoke SQL Supabase published) or with grants-lint's since setting. Without one of those, the rule stays quiet after 2026-10-30 too. Once it's recorded, every table your next migration creates gets checked at the call site, in your editor, before the request fails in production.

What it found in 99 public repos

I ran the recommended config over 99 public repositories that have Supabase migrations, TypeScript sources and supabase-js. I pinned the commits and linted them as they are. Out of those 99:

35 of 99 (35.4%) had at least one finding.
15 of 99 (15.2%) subscribed with postgres_changes to a table their migrations never add to the publication.
11 of 99 (11.1%) had a read, update or delete that row level security turns into a silent no-op, by their own migrations.
8 of 99 (8.1%) had a query that's never sent, either voided or left floating.
29 of 99 (29.3%) had a .subscribe() with no status callback.
2 of 99 (2.0%) already had a call with no privilege behind it, before the change.

Some honest caveats. The corpus only sees migrations, so a table published or a policy added by hand in the dashboard is invisible to it, and a finding can be right about the migrations and still not happen in that repo's production database. It's not a random sample of Supabase apps either. Calls the plugin can't resolve are skipped, so treat these numbers as lower bounds. I also did a blind hand review of 50 schema findings, drawn at random from a fresh run I hadn't looked at before. It turned up 2 false positives (4.0%), and one of those came from my own corpus harness and is fixed. I'm not naming any of the repositories, and I won't.

Try it

You'll need a TypeScript project with typed linting:

npm install --save-dev eslint-plugin-supabase eslint @typescript-eslint/parser "typescript@>=5.8 <6.1"

// eslint.config.mjs
import parser from '@typescript-eslint/parser';
import supabase from 'eslint-plugin-supabase';

export default [
  {
    files: ['**/*.ts', '**/*.tsx'],
    ignores: ['**/supabase/functions/**'],
    languageOptions: {
      parser,
      parserOptions: { projectService: true, tsconfigRootDir: import.meta.dirname },
    },
  },
  supabase.configs.recommended,
];

Then run npx eslint .. The ignores line keeps Deno edge functions out of typed linting. The two code rules work on any project. The three schema rules look for supabase/migrations next to your code (and read grants-lint.config.json if you have one). If you created your tables in the dashboard, run supabase db pull once so your migrations actually create them. The plugin doesn't open a network connection, doesn't read your .env file and doesn't send telemetry.

One more step for the 2026-10-30 change. Once your project is past it (or you opted in early from the dashboard), tell the replay: add the opt-in migration (the revoke SQL Supabase published), or set since in grants-lint.config.json to the version of your last migration before the change. Without one of those, the replay keeps the old automatic grants and table-granted stays quiet on new tables.

How I built it

The schema rules don't parse SQL themselves. They use the replay engine from supabase-grants-lint, the migration linter I wrote for the same change, through a new engine export. That way the CLI and the editor agree on what your migrations mean.

Before writing this, I pointed the plugin at the history of the app where both incidents happened. At the commit before the void fix, no-unsent-query reports the call. At the fix, it goes quiet. The subscription was harder. That app adds tables to the publication inside a do block, which a replay can't read, so the plugin skips those subscriptions instead of guessing (reportUnresolved names the block and asks for plain alter publication statements). With the block rewritten as plain statements, realtime-table-published reports the unpublished subscription and nothing else.

Every guard in the rules is mutation-tested, and every rule has a test for each case it leaves alone on purpose.

It doesn't check the 1,000-row PostgREST limit. For that, use rowcap by anabecalab, which does it well.

Try it on your project

Run it once before 2026-10-30. If it finds something, or flags something that isn't a bug, please open an issue. A false positive is a bug, and I want to fix it this week.

I used AI to help draft and edit this post; the plugin, the tests and the numbers are mine.

Not affiliated with or endorsed by Supabase.

Supabase stops auto-granting on Oct 30. Here is what breaks, and five traps the changelog does not mention.

Aman Gupta — Tue, 29 Sep 2026 13:10:00 +0000

I replayed the migration histories of 100 public Supabase projects on a database without automatic grants. In 98 of them, at least one table ended up unreachable through the Data API for some role. In 92, at least one row level security policy could never apply, because the role it names lacks the privilege the policy's command needs. Not one of the 100 histories contains the opt-in migration.

That is not a statement about those projects' production databases: existing tables keep their grants. It is a statement about what their next table, their next preview branch, or their next fresh environment will look like. Here is why, and what to look for.

What changes

Supabase has announced that from 2026-10-30, new tables, views and sequences in the public schema stop getting automatic grants for anon, authenticated and service_role on every existing project (announcement).

Until now, a default privilege did the work for you. postgres created a table in public, and the three API roles got access to it immediately. You wrote your row level security policies and forgot that grants existed at all.

After the change, you need to say it:

create table public.todos (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users (id),
  title text not null
);

alter table public.todos enable row level security;

create policy "read own todos" on public.todos
  for select to authenticated using (auth.uid() = user_id);

-- the new part
grant select on public.todos to authenticated;
grant select, insert, update, delete on public.todos to service_role;

Forget the last two lines and nothing complains. The migration applies cleanly, the policy looks right in the dashboard, and the first request returns:

{ "code": "42501", "message": "permission denied for table todos" }

Existing tables are not affected. The risk is every table you create from now on, and every environment that is built from your migration history instead of from production.

Five traps

These are the parts that are easy to miss, even after reading the announcement.

1. Replaying your history turns the grants back on

If your first migration came from supabase db pull, it probably contains lines like these:

alter default privileges for role "postgres" in schema "public"
  grant all on tables to "anon";
alter default privileges for role "postgres" in schema "public"
  grant all on tables to "authenticated";
alter default privileges for role "postgres" in schema "public"
  grant all on tables to "service_role";

pg_dump copies your default privileges as they were when you pulled. Replay that file on a preview branch or a local supabase db reset, and every table your later migrations create gets full access again. Supabase's own branching docs say so. Production no longer has those defaults, so the table that works in your preview branch fails once it ships.

The local stack has a second version of the same trap: with the current CLI, new tables are exposed automatically unless you set auto_expose_new_tables = false under [api] in supabase/config.toml. A local test run tells you nothing about grants.

Of the 100 histories, 2 end with default grants still switched on by their own statements, after replaying every file. The fix is a migration that switches them off again, after the baseline.

2. The revoke is narrow

Per the SQL Supabase published, the opt-in removes select, insert, update and delete on tables, and usage and select on sequences:

alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;
alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;

The old default was grant all. So truncate, references and trigger (plus maintain on Postgres 17 and later) still go to anon and authenticated on every new table. Row level security does not apply to truncate or references. If you want clients to hold only what you granted, revoke the rest yourself:

revoke truncate, references, trigger on public.todos from anon, authenticated;

3. `service_role` bypasses row level security, not grants

A common assumption is that the service role key can do anything. It bypasses policies, but Postgres checks privileges before it looks at policies, and service_role is not a superuser. Your edge functions, cron jobs and admin tools that use the service role key get the same 42501 on a table nobody granted to service_role.

grant select, insert, update, delete on public.audit_log to service_role;

This was the most common finding in the corpus: 97 of the 100 histories create at least one table service_role cannot read or write without the automatic grants.

4. Policies without grants are dead

A policy never grants access. It only narrows access a role already has. This policy:

create policy "insert own messages" on public.messages
  for insert to authenticated with check (auth.uid() = sender_id);

does nothing unless authenticated holds insert on public.messages. Without the grant, the request fails before the policy is evaluated. The policy looks like access control, reads like access control, and never runs.

In 87 of the 100 histories, a table has policies for anon or authenticated while that role holds no data privilege on it at all. Counting every mismatch, including a for update policy on a table the role can only select, 92 have at least one policy that can never apply.

5. `serial` columns need their sequence

create table public.orders (
  id bigserial primary key,
  user_id uuid not null,
  total numeric not null
);
grant select, insert on public.orders to authenticated;

The insert still fails. A serial column's default calls nextval() on its own sequence, and nextval() needs usage (or update) on that sequence. The announced revoke removes sequence usage too:

grant usage on sequence public.orders_id_seq to authenticated;

Identity columns (generated always as identity) and uuid keys do not need this: Postgres does not check sequence privileges for identity columns, and gen_random_uuid() uses no sequence at all. This one is rare (1 history in the corpus), but when it happens the error names a sequence nobody remembers creating.

How the numbers were measured

The corpus is 100 public GitHub repositories with at least three files in supabase/migrations, pushed within the last year, not forks, each pinned to a commit. Median history length: 30 migrations. Each history was replayed twice: once as a database without automatic grants would build it (every migration checked), and once as the project is configured today.

In total the replays flagged 5,820 distinct tables and views as unreachable for at least one role, a median of 21 per project (for scale, 6,601 relations are in scope at the end of the histories). The parser read 103,326 statements and rejected 0.4% of them; each kind of rejected statement was checked against its source, and all were invalid SQL, syntax Postgres does not have, or not SQL at all. Results are published as aggregates only; no project is named.

Check your own project

I turned these checks into a linter:

npx supabase-grants-lint check

Run it from your project root, the folder that contains supabase/. If your migrations live somewhere else, point at them: npx supabase-grants-lint check --dir db/migrations.

It reads your migrations, replays them in order into a model of who holds which privilege on which table and sequence, and prints the grant that fixes each finding:

supabase/migrations/20261002120000_add_todos.sql
  1:1   error  GL001  public.todos is created without a grant to service_role: ...
               fix   grant select, insert, update, delete on public.todos to service_role;
  10:1  error  GL003  Policy "read own todos" on public.todos is for select by authenticated,
                      but authenticated holds no select privilege on it: ...
               fix   grant select on public.todos to authenticated;

npx supabase-grants-lint doctor gives a readiness report: whether an opt-in migration exists, whether replaying the history turns automatic grants back on, and which existing tables a fresh database would not expose.

To keep it from happening again, run it on every pull request:

npx supabase-grants-lint init --since next

This writes a config and a GitHub Actions workflow. --since next enforces every migration you add from now on and leaves your history alone, so you do not have to fix a long history before you can turn it on. Findings show up as annotations on the pull request.

It reads files only. It never connects to your database and sends no telemetry.

How it was built

This started as a test in a production app with about 60 tables. When I opted that project in early, I wanted proof that every table would still be reachable, so I wrote a test that replayed the whole migration history and compared the result with the grants production actually had. Every trap above is something that test caught.

The open source version is a rewrite, not a copy. It parses migrations with the real Postgres parser (compiled to WebAssembly), and replays them through a small model of grants, default privileges, sequences and policies. Every rule has failing and passing fixtures, and the rules and the model are mutation-tested, so a check that stops catching its bug fails the build. Before release, it ran over the corpus above, and every false positive I found in a hand-checked sample became a fixture and a fix.

Try it before Oct 30

Run npx supabase-grants-lint doctor on your project.
Add the GitHub Action, so the next migration is checked before it ships.
If it flags something that works, or misses something that does not, please open an issue with the SQL: false-positive reports are the most useful thing you can send.

The code is MIT licensed at github.com/guptaaman678/supabase-grants-lint. A star helps other people find it before the deadline.