feat(dashboard-api): supabase auth users sync background runner by ben-fornefeld · Pull Request #2247 · e2b-dev/infra

ben-fornefeld · 2026-03-28T00:23:50Z

No description provided.

cursor · 2026-03-28T00:23:57Z

PR Summary

Medium Risk
Adds DB triggers/migrations and a new River background worker that mutates public.users based on auth DB events; misconfiguration or migration issues could lead to missed/duplicated sync jobs or unintended data changes. Also changes deployment env injection, which could affect runtime config if incorrect vars are passed.

Overview
Adds an optional dashboard-api background worker (gated by AUTH_USER_SYNC_BACKGROUND_WORKER_ENABLED) that uses River jobs to mirror auth.users inserts/updates/deletes into public.users, including new auth-DB migrations for an auth_custom schema and triggers that enqueue jobs. Updates GCP/Nomad Terraform to accept a DASHBOARD_API_ENV_VARS map and merge it into the job environment with a precondition preventing overrides of reserved keys, and tweaks local dashboard-api make targets to apply the same extra env vars at runtime; dependency bumps include pgx and new River-related modules.

^{Written by Cursor Bugbot for commit 638429a. This will update automatically on new commits. Configure here.}

packages/db/pkg/auth/sql_queries/supabase_auth_user_sync/get_auth_user.sql

claude · 2026-03-28T00:29:00Z

packages/db/pkg/dashboard/migrations/20260328000000_dashboard_supabase_auth_user_sync_queue.sql

+);
+
+CREATE INDEX auth_user_sync_queue_pending_idx
+    ON auth.user_sync_queue (id)


The partial index only covers dead_lettered_at IS NULL AND locked_at IS NULL, so every unlocked non-dead-lettered row satisfies it — including rows with a future next_attempt_at. The claim query then discards those rows in a post-index filter. Under sustained retry load (many rows waiting with next_attempt_at > now()), the index returns a large candidate set that must be filtered in-memory before the LIMIT is applied. Adding next_attempt_at as the leading column — ON auth.user_sync_queue (next_attempt_at, id) WHERE dead_lettered_at IS NULL AND locked_at IS NULL — lets PostgreSQL range-scan only rows that are actually ready to be claimed.

claude · 2026-03-28T00:29:00Z

packages/dashboard-api/internal/supabaseauthusersync/runner.go

+
+	r.l.Debug(ctx, "claimed queue batch", zap.Int("count", len(items)))
+
+	for _, item := range items {


Items in a batch are processed sequentially. Each item does 2–3 synchronous DB round-trips (GetAuthUser + UpsertPublicUser/DeletePublicUser + Ack/Retry), so batch throughput is proportional to batchSize × DB latency. With the default BatchSize=50 and typical Postgres latency, a full batch can take several seconds — longer than PollInterval=2s. If sustained write volume is expected, consider processing items in a small goroutine pool.

packages/dashboard-api/internal/supabaseauthusersync/config.go

… while enqueuing for processing

…om/e2b-dev/infra into feature/supabase-users-sync-worker

…d recovery mechanisms - Updated the sync runner to use `RunWithRestart` for improved error recovery. - Introduced a new `UserSyncQueue` model to manage user synchronization tasks. - Added SQL migration for creating the `user_sync_queue` table with necessary triggers. - Implemented tests for the processor and supervisor to ensure robust handling of retries and panics. - Refactored existing queries to target the new `public.user_sync_queue` table.

packages/dashboard-api/internal/supabaseauthusersync/runner_test.go

…agement - Introduced `supabase_auth_user_sync_enabled` variable to control user synchronization. - Updated Nomad job configuration to include the new sync setting. - Added Google Secret Manager resources for managing the sync configuration securely. - Enhanced the dashboard API to utilize the new sync configuration in processing logic. - Refactored related components to improve error handling and logging for the sync process.

packages/dashboard-api/internal/supabaseauthusersync/store.go

packages/dashboard-api/internal/supabaseauthusersync/config.go

packages/dashboard-api/internal/supabaseauthusersync/runner_test.go

packages/dashboard-api/main.go

iac/provider-gcp/nomad/main.tf

- Replaced the previous `Store` implementation with a new structure that integrates both authentication and main database queries. - Updated the `Runner` and `NewRunner` functions to accommodate the new database client structure. - Removed obsolete SQL queries and migration files related to the `user_sync_queue` table. - Enhanced the test suite to reflect changes in the runner's initialization and database interactions.

- Updated the `TestSupabaseAuthUserSyncRunner_EndToEnd` to apply necessary database migrations before running tests. - Refactored the `SetupDatabase` function to include a new method `ApplyMigrations` for better migration management.

Made-with: Cursor

packages/dashboard-api/main.go

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3f56979748

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

iac/provider-gcp/api.tf

chatgpt-codex-connector · 2026-04-01T01:03:18Z

packages/db/pkg/auth/migrations/20260328000001_dashboard_supabase_auth_user_sync_queue.sql

+-- +goose Up
+-- +goose StatementBegin
+CREATE TABLE public.user_sync_queue (


Ensure auth queue migration is executed by db-migrator

The queue/table trigger migration was added under packages/db/pkg/auth/migrations, but the deployed migrator workflow only runs ./migrations from packages/db/scripts/migrator.go (and the db Dockerfile only copies db/migrations). That means the standard prestart migration job will never create public.user_sync_queue or the new triggers, so enabling the sync worker will fail at runtime when it tries to claim from a non-existent table.

Useful? React with 👍 / 👎.

we want to execute this manually + it should not be tied to main db migrations since authDB will be separate going forward

iac/provider-gcp/nomad/main.tf

- Introduced a new process outcome `ready_to_ack` to streamline acknowledgment handling. - Refactored the `process` method to prepare for batch acknowledgment of processed items. - Added a new `AckBatch` method in the store to handle multiple acknowledgments efficiently. - Updated the `Runner` to process items in batches and finalize acknowledgments accordingly. - Removed obsolete SQL query for single item acknowledgment as part of the refactor. - Enhanced tests to cover new deletion logic and acknowledgment scenarios.

iac/provider-gcp/nomad/main.tf

claude · 2026-04-01T01:09:12Z

packages/db/pkg/auth/sql_queries/supabase_auth_user_sync/get_auth_user.sql

+-- name: GetAuthUserByID :one
+SELECT id, email
+FROM auth.users
+WHERE id = sqlc.arg(user_id)::uuid;


🔴 The SQL query selects email from auth.users without null handling, and the generated AuthUser.Email field is a non-nullable string; Supabase supports phone-only and anonymous auth where email is NULL, so pgx returns a scan error (not pgx.ErrNoRows) for those users. In reconcile(), that error triggers the generic retry path, causing indefinite retries until the item is dead-lettered and the user is never synced to public.users. Fix by changing the query to COALESCE(email, '') or by mapping Email to *string and skipping the upsert when absent.

Extended reasoning...

What the bug is and how it manifests

The file packages/db/pkg/auth/sql_queries/supabase_auth_user_sync/get_auth_user.sql (lines 1-4) contains:

-- name: GetAuthUserByID :one SELECT id, email FROM auth.users WHERE id = sqlc.arg(user_id)::uuid;

The generated code in get_auth_user.sql.go scans the result into AuthUser, whose Email field is declared as a non-nullable string in models.go. In pgx v5, scanning a SQL NULL into a plain Go string returns a scan error — it does not return pgx.ErrNoRows.

The specific code path that triggers it

In processor.go, reconcile() calls p.store.GetAuthUser(ctx, item.UserID). It checks errors.Is(err, pgx.ErrNoRows) to decide whether to delete the public user. A NULL-email scan error is not pgx.ErrNoRows, so it falls into the generic if err != nil { return "", fmt.Errorf(...) } branch, which propagates back to process(). Since the item is not yet at maxAttempts, process() calls store.Retry(...), scheduling the item for another attempt with exponential backoff.

Why existing code does not prevent it

The reconcile() function only has two exit paths for errors from GetAuthUser: the pgx.ErrNoRows special case (leading to a delete) and a generic retry path. There is no handling for scan errors caused by NULL columns, and no defensive COALESCE or nullable type in the generated SQL/struct.

Impact

Any Supabase deployment using phone-only or anonymous authentication will have users with auth.users.email = NULL. Every such user that enters the sync queue will be retried up to MaxAttempts (default 20) times with growing backoffs and then dead-lettered. Those users are permanently excluded from public.users, causing any feature that relies on public.users to silently omit them.

How to fix it

The simplest fix is to add COALESCE in the SQL query:

SELECT id, COALESCE(email, '') AS email FROM auth.users WHERE id = sqlc.arg(user_id)::uuid;

Alternatively, change the sqlc config so email maps to *string, update AuthUser.Email to *string, and skip the upsert (or pass an empty string) when Email is nil.

Step-by-step proof

A Supabase phone-only user signs up. The auth.users row has id = <uuid>, email = NULL.

The sync_insert_auth_users_to_public_users_trigger fires, inserting (user_id, 'upsert') into public.user_sync_queue.

The worker calls ClaimBatch, picks up the item, increments attempt_count to 1.

processor.process() -> processOnce() -> reconcile() -> store.GetAuthUser(ctx, userID).

GetAuthUserByID executes SELECT id, email FROM auth.users WHERE id = $1. The row exists so pgx does not return pgx.ErrNoRows. Instead row.Scan(&i.ID, &i.Email) attempts to scan NULL into string and returns a pgx scan error.

Back in reconcile(), errors.Is(err, pgx.ErrNoRows) is false. The error is returned as fmt.Errorf("get auth.users %s: %w", ...).

process() sees item.AttemptCount (1) < maxAttempts (20), so it calls store.Retry(...) with a 5s backoff.

Steps 3-7 repeat until attempt_count >= 20, at which point DeadLetter is called.

The user is now dead-lettered and will never be synced to public.users.

fine, we require emails for auth

claude · 2026-04-01T01:09:12Z

iac/modules/job-dashboard-api/jobs/dashboard-api.hcl

+        %{ for key, val in env }
+        ${ key }   = "${ val }"
+        %{ endfor }


🟡 The %{ for key, val in env } loop in dashboard-api.hcl renders env var values directly inside double-quoted HCL strings without escaping. A value containing a double-quote produces syntactically invalid HCL (Nomad job submission fails), and a value containing ${ causes Terraform templatefile() to attempt expression evaluation at render time (plan-time error). DASHBOARD_API_ENV_VARS is documented as accepting arbitrary operator-supplied values, making these characters plausible; fix by escaping double-quotes in values or passing extra env vars via a Nomad template stanza instead.

Extended reasoning...

What the bug is and how it manifests

In iac/modules/job-dashboard-api/jobs/dashboard-api.hcl lines 86-88, a Terraform templatefile() directive renders arbitrary env var values directly inside double-quoted HCL strings:

%{ for key, val in env } ${ key } = "${ val }" %{ endfor }

Two distinct injection vectors exist. First, if val contains a double-quote character, the rendered output becomes syntactically invalid HCL (e.g. MY_VAR = "conn"string" breaks the HCL parser), causing Nomad to reject the job spec at submit time. Second, if val contains ${, Terraform's templatefile() function interprets it as an expression interpolation during template rendering and produces a plan-time error before the job is ever submitted.

The specific code path that triggers it

The value flows through: DASHBOARD_API_ENV_VARS env var -> parsed as map(string) in iac/provider-gcp/variables.tf -> passed to module.nomad as dashboard_api_env_vars -> passed to module.dashboard_api as env -> filtered in local.env in main.tf (removes null/empty only) -> passed to templatefile() -> rendered at line 87 with no escaping.

Why existing code does not prevent it

The locals block in main.tf only filters out null/empty values (if value != null && value != ""); it does not escape or sanitize values. Terraform's templatefile() does not automatically escape template variable contents when they are interpolated. The HCL string delimiters are hard-coded double quotes with no escaping mechanism.

What the impact would be

For a double-quote injection (e.g. a PostgreSQL DSN like postgresql://user:p"ass@host/db), the Nomad job submission fails at terraform apply time with an HCL parse error -- the deployment is blocked. For a ${ injection (e.g. a JWT secret or template string containing ${), Terraform fails during plan or apply with an evaluation error. Neither failure is silent, but both are surprising and difficult to debug without knowing the root cause.

How to fix it

The safest fix is to use replace(val, "\"", "\\\"") to escape double-quotes within the current templatefile() approach, or pass extra env vars through a Nomad template stanza which has proper escaping semantics. The ${ vector can be addressed by replacing ${ with $${ (Terraform's escape sequence for a literal ${).

Step-by-step proof

Operator sets DASHBOARD_API_ENV_VARS='{"DB_URL":"postgresql://user:p\"ass@host/db"}' in their env file.

Terraform receives var.dashboard_api_env_vars = {DB_URL = "postgresql://user:p\"ass@host/db"}.

local.env passes it through unchanged (non-null, non-empty).

templatefile() renders line 87 as: DB_URL = "postgresql://user:p"ass@host/db" -- the embedded " terminates the HCL string prematurely.

Nomad's job spec parser receives invalid HCL and rejects the job with a parse error.

Alternatively, for a value containing ${SOME_VAR}: templatefile() evaluates ${SOME_VAR} as a Terraform expression, returning an undefined variable error during terraform apply.

Note: the identical ${ key } = "${ value }" pattern exists in job-api and job-orchestrator for their job_env_vars, but those maps contain hardcoded infrastructure constants (VOLUME_TOKEN_ISSUER, etc.) unlikely to contain special characters. The new DASHBOARD_API_ENV_VARS is explicitly documented as a freeform map for arbitrary operator-supplied values, removing that safety assumption.

…om/e2b-dev/infra into feature/supabase-users-sync-worker

dobrac

Looks so much simpler with the library!

dobrac · 2026-04-02T05:44:41Z

packages/dashboard-api/internal/backgroundworker/auth_user_sync.go

+		metric.WithUnit("{job}"),
+	)
+	if err != nil {
+		l.Warn(context.Background(), "failed to initialize auth user sync metric", zap.Error(err))


lets pass the context as a parameter

dobrac · 2026-04-02T05:45:34Z

packages/db/pkg/auth/migrations/20260401000001_river_auth_custom_schema.sql

+-- +goose Down
+-- +goose StatementBegin
+
+/* We don't want to drop the schema, as it is used by other services. */


why not drop the schema here if the dashboard-api is the source of truth?

belt has a migration that creates this schema. we don't want to delete that accidentally but i guess we can add the down migration here and just execute the migration manually

dobrac · 2026-04-02T05:46:23Z

packages/db/pkg/auth/queries/ack.sql.go

what are these files generated from?

good catch. these were artifacts that the generator did not clean up manually

dobrac · 2026-04-02T05:47:47Z

packages/dashboard-api/Makefile

 	make build
-	NODE_ID=$(HOSTNAME) ./bin/dashboard-api
+	@EXTRA_ENV=$(DASHBOARD_API_EXTRA_ENV); \
+	eval "env NODE_ID=$(HOSTNAME) $$EXTRA_ENV ./bin/dashboard-api"


is the usage of eval safe (secure) here? Can we avoid it?

i think it was fine but i cleaned it up to not rely on eval

dobrac · 2026-04-02T05:48:51Z

packages/dashboard-api/Makefile

 HOSTNAME := $(shell hostname 2> /dev/null || hostnamectl hostname 2> /dev/null)
 $(if $(HOSTNAME),,$(error Failed to determine hostname: both 'hostname' and 'hostnamectl' failed))

+define DASHBOARD_API_EXTRA_ENV


I think it might have been simpler to expose the env variable directly rather than having it nested under extra env

i had a conversation with @djeebus on this but, i think this way it's much simpler adding environment variables to our dev setups, without the need to put it inside secrets or hook up a new makefile -> terraform -> nomad code path

dobrac · 2026-04-02T05:49:56Z

packages/dashboard-api/main.go

+	if config.SupabaseAuthUserSyncEnabled {
+		workerLogger := l.With(zap.String("worker", "supabase_auth_user_sync"))
+
+		authPool := authDB.WritePool()


the authDB is not Supabase DB, but a preparation for a future split of public.users, public.teams, etc to its own database

is this about the naming of the config?

…riable handling - Updated the AuthUserSyncWorker to utilize OpenTelemetry metrics for better monitoring. - Refactored the Makefile to improve environment variable exportation and streamline build/run commands. - Removed outdated SQL query files related to user sync queue operations to clean up the codebase. - Adjusted the database migration script to drop the auth_custom schema if it exists, ensuring a cleaner migration process.

packages/db/pkg/auth/migrations/20260401000003_river_auth_user_sync_triggers.sql

Made-with: Cursor

.env.gcp.template

Use AUTH_USER_SYNC_BACKGROUND_WORKER_ENABLED instead of SUPABASE_AUTH_USER_SYNC_ENABLED to match the actual config field in packages/dashboard-api/internal/cfg/model.go Co-authored-by: Ben Fornefeld <ben-fornefeld@users.noreply.github.com>

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

packages/db/pkg/auth/migrations/20260401000003_river_auth_user_sync_triggers.sql

…n auth_custom schema - Changed REVOKE statement to specify INSERT permission on river_job. - Added REVOKE for USAGE and SELECT on all sequences in the auth_custom schema for trigger_user.

…om/e2b-dev/infra into feature/supabase-users-sync-worker

djeebus · 2026-04-03T20:26:30Z

iac/modules/job-dashboard-api/jobs/dashboard-api.hcl

+        %{ for key in sort(keys(env)) ~}
+        ${key} = "${env[key]}"
+        %{ endfor ~}


You don't need to sort it manually; terraform does it for you:

Suggested change

%{ for key in sort(keys(env)) ~}

${key} = "${env[key]}"

%{ endfor ~}

%{ for key, value in env ~}

${key} = "${value}"

%{ endfor ~}

djeebus · 2026-04-03T20:27:21Z

iac/modules/job-dashboard-api/main.tf

+  conflicting_extra_env_keys = sort(tolist(setintersection(
+    toset(keys(local.base_env)),
+    toset(keys(local.extra_env)),
+  )))


This is kind of an anti-pattern. If someone sets the values above, it's b/c they wanted to override it. We shouldn't forbid it.

djeebus · 2026-04-03T20:27:53Z

iac/modules/job-dashboard-api/main.tf

+  extra_env = {
+    for key, value in var.extra_env : key => value
+    if value != null && trimspace(value) != ""
+  }


Why? Empty strings are valid env vars, and could be distinct from populated values.

djeebus · 2026-04-03T20:36:57Z

packages/dashboard-api/internal/backgroundworker/config.go

+	// must match the schema used in packages/db/pkg/auth/migrations for River tables and triggers
+	AuthCustomSchema = "auth_custom"
+
+	// must match the queue value in packages/db/pkg/auth/migrations trigger SQL inserts
+	AuthUserProjectionQueue = "auth_user_projection"
+
+	// must match the kind value in packages/db/pkg/auth/migrations trigger SQL inserts
+	AuthUserProjectionKind = "auth_user_projection"
+
+	AuthUserProjectionMaxWorkers = 10


Let's unexport these. The constants don't add value to the one log message they're attached to. If we really want to log them out, add something like "client configured with " in the NewRiverClient function. Keeping them private gives us more flexibility wrt refactors in the future.

djeebus · 2026-04-03T20:47:16Z

packages/dashboard-api/internal/backgroundworker/auth_user_sync_test.go

+
+	authMigrationsDir := "packages/db/pkg/auth/migrations"
+
+	db.ApplyMigrationsUpTo(t, 20260401000001, authMigrationsDir)


To ensure that future tests function correctly, I'd migrate to latest every time.

djeebus · 2026-04-03T20:48:53Z

packages/dashboard-api/internal/backgroundworker/auth_user_sync_test.go

+	runUpsertProjection(t, db)
+	runDeleteProjection(t, db)
+	runBurstBacklog(t, db)


This test scares me in general. I'd much rather have a 200 line test that makes clear setup steps, action steps, and verification steps (even if they're interleaved). It's really unclear what this test does, and why it does it.

djeebus · 2026-04-03T20:49:52Z

packages/dashboard-api/internal/cfg/model.go

 	RedisClusterURL  string `env:"REDIS_CLUSTER_URL"`
 	RedisTLSCABase64 string `env:"REDIS_TLS_CA_BASE64"`
+
+	AuthUserSyncBackgroundWorkerEnabled bool `env:"AUTH_USER_SYNC_BACKGROUND_WORKER_ENABLED" envDefault:"false"`


We should probably avoid the yoda-speak:

Suggested change

AuthUserSyncBackgroundWorkerEnabled bool `env:"AUTH_USER_SYNC_BACKGROUND_WORKER_ENABLED" envDefault:"false"`

EnableAuthUserSyncBackgroundWorker bool `env:"ENABLE_AUTH_USER_SYNC_BACKGROUND_WORKER" envDefault:"false"`

djeebus · 2026-04-03T20:55:09Z

packages/dashboard-api/internal/backgroundworker/auth_user_sync.go

+	userID, err := uuid.Parse(job.Args.UserID)
+	if err != nil {
+		telemetry.ReportError(ctx, "auth user sync parse user_id", err, attrs...)
+		w.observeJob(ctx, job.Args.Operation, "cancelled")


maybe "validation-failed" or "invalid arguments" instead?

djeebus · 2026-04-03T20:56:46Z

packages/dashboard-api/internal/backgroundworker/auth_user_sync.go

+		if job.Args.Email == "" {
+			err := fmt.Errorf("missing email in job args for user %s", userID)
+			telemetry.ReportError(ctx, "auth user sync missing email", err, attrs...)
+			w.observeJob(ctx, job.Args.Operation, "cancelled")


"invalid argument"?

djeebus · 2026-04-03T20:57:05Z

packages/dashboard-api/internal/backgroundworker/auth_user_sync.go

+	default:
+		err := fmt.Errorf("unknown operation %q for user %s", job.Args.Operation, userID)
+		telemetry.ReportError(ctx, "auth user sync unknown operation", err, attrs...)
+		w.observeJob(ctx, job.Args.Operation, "cancelled")


"invalid argument"?

djeebus · 2026-04-03T20:59:05Z

packages/dashboard-api/main.go

+		workerLogger := l.With(zap.String("worker", backgroundworker.AuthUserProjectionKind))
+		workerMeter := tel.MeterProvider.Meter("github.com/e2b-dev/infra/packages/dashboard-api")
+
+		authPool := authDB.WritePool()
+		if err := backgroundworker.RunRiverMigrations(ctx, authPool); err != nil {
+			l.Fatal(ctx, "failed to run River migrations on auth DB", zap.Error(err))
+		}
+
+		workers := river.NewWorkers()
+		river.AddWorker(workers, backgroundworker.NewAuthUserSyncWorker(ctx, db, workerMeter, workerLogger))
+
+		riverClient, err = backgroundworker.NewRiverClient(authPool, workers)
+		if err != nil {
+			l.Fatal(ctx, "failed to create River client", zap.Error(err))
+		}
+
+		if err := riverClient.Start(signalCtx); err != nil {
+			l.Fatal(ctx, "failed to start River client", zap.Error(err))
+		}
+
+		l.Info(ctx, "background worker started", zap.String("queue", backgroundworker.AuthUserProjectionQueue), zap.String("schema", backgroundworker.AuthCustomSchema))


maybe cleaner to put this in it's own function: setupRiverWorker or something

djeebus · 2026-04-03T21:03:34Z

packages/dashboard-api/Makefile

 $(if $(HOSTNAME),,$(error Failed to determine hostname: both 'hostname' and 'hostnamectl' failed))

+define export_extra_env
+export $$(printf '%s' "$$DASHBOARD_API_ENV_VARS" | jq -r '(if .=="" then empty elif type=="string" then (fromjson? // empty) else . end) | to_entries? // [] | map("\(.key)=\(.value|tostring)") | .[]' 2>/dev/null) 2>/dev/null;


Where are you defining these? You could just run ENV=a ENV=bb make run and it'll receive both those env vars

djeebus · 2026-04-03T21:04:42Z

packages/db/pkg/testutils/db.go

+func (db *Database) ApplyMigrationsUpTo(t *testing.T, version int64, migrationDirs ...string) {
+	t.Helper()
+
+	db.applyGooseMigrations(t, version, migrationDirs...)


I don't think we should ever be running tests on an old version of the database. These tests will be stale as soon as a new migration is created, then we'll be testing that new code works against old dbs, which servers no purpose.

djeebus

Bunch of comments; none are critical, just a lot of clean up.

feat: supabase auth users sync background runner in dashboard api

c50d248

e2b-request-same-site-reviewers bot assigned dobrac Mar 28, 2026

chore: auto-commit generated changes

68a6265

claude bot reviewed Mar 28, 2026

View reviewed changes

cursor bot reviewed Mar 28, 2026

View reviewed changes

packages/dashboard-api/internal/supabaseauthusersync/config.go Outdated Show resolved Hide resolved

ben-fornefeld added 3 commits March 30, 2026 11:53

feat(db): enhance auth user sync triggers to retain direct operations…

9d8fe63

… while enqueuing for processing

Merge branch 'feature/supabase-users-sync-worker' of https://github.c…

1e5f28b

…om/e2b-dev/infra into feature/supabase-users-sync-worker

cursor bot reviewed Mar 30, 2026

View reviewed changes

packages/dashboard-api/internal/supabaseauthusersync/runner_test.go Outdated Show resolved Hide resolved

cursor bot reviewed Mar 31, 2026

View reviewed changes

packages/dashboard-api/internal/supabaseauthusersync/store.go Outdated Show resolved Hide resolved

packages/dashboard-api/internal/supabaseauthusersync/config.go Outdated Show resolved Hide resolved

chore: remove smoke test

eb69678

cursor bot reviewed Mar 31, 2026

View reviewed changes

packages/dashboard-api/internal/supabaseauthusersync/runner_test.go Outdated Show resolved Hide resolved

ben-fornefeld added 2 commits March 31, 2026 13:49

add: e2e runner test

bb9fa39

chore: change dashboard-api env variable management

461d2ec

cursor bot reviewed Mar 31, 2026

View reviewed changes

packages/dashboard-api/main.go Outdated Show resolved Hide resolved

iac/provider-gcp/nomad/main.tf Outdated Show resolved Hide resolved

ben-fornefeld added 4 commits March 31, 2026 16:04

fix: lint

4d622ce

Merge origin/main into feature/supabase-users-sync-worker

3f56979

Made-with: Cursor

ben-fornefeld added the feature New feature label Apr 1, 2026

cursor bot reviewed Apr 1, 2026

View reviewed changes

packages/dashboard-api/main.go Outdated Show resolved Hide resolved

ben-fornefeld marked this pull request as ready for review April 1, 2026 00:56

ben-fornefeld requested review from ValentaTomas, dobrac and jakubno as code owners April 1, 2026 00:56

chatgpt-codex-connector bot reviewed Apr 1, 2026

View reviewed changes

claude bot reviewed Apr 1, 2026

View reviewed changes

github-actions bot and others added 3 commits April 2, 2026 02:22

chore: auto-commit generated changes

e314b96

improve: retrying for river jobs

db124a4

Merge branch 'feature/supabase-users-sync-worker' of https://github.c…

0e7f147

…om/e2b-dev/infra into feature/supabase-users-sync-worker

dobrac requested changes Apr 2, 2026

View reviewed changes

cursor bot reviewed Apr 2, 2026

View reviewed changes

packages/db/pkg/auth/migrations/20260401000003_river_auth_user_sync_triggers.sql Show resolved Hide resolved

chore: rename config and fix test

8226f67

cursor bot reviewed Apr 2, 2026

View reviewed changes

packages/db/pkg/auth/migrations/20260401000003_river_auth_user_sync_triggers.sql Outdated Show resolved Hide resolved

ben-fornefeld and others added 3 commits April 2, 2026 12:16

improve: config

8485d7a

Merge origin/main into feature/supabase-users-sync-worker

37f842f

Made-with: Cursor

chore: auto-commit generated changes

c0b1102

cursor bot reviewed Apr 2, 2026

View reviewed changes

.env.gcp.template Outdated Show resolved Hide resolved

cursor bot reviewed Apr 2, 2026

View reviewed changes

packages/db/pkg/auth/migrations/20260401000003_river_auth_user_sync_triggers.sql Outdated Show resolved Hide resolved

ben-fornefeld added 2 commits April 2, 2026 19:32

fix: update permissions for trigger_user on river_job and sequences i…

45a7ccb

…n auth_custom schema - Changed REVOKE statement to specify INSERT permission on river_job. - Added REVOKE for USAGE and SELECT on all sequences in the auth_custom schema for trigger_user.

Merge branch 'feature/supabase-users-sync-worker' of https://github.c…

638429a

…om/e2b-dev/infra into feature/supabase-users-sync-worker

djeebus reviewed Apr 3, 2026

View reviewed changes

djeebus approved these changes Apr 3, 2026

View reviewed changes


		r.l.Debug(ctx, "claimed queue batch", zap.Int("count", len(items)))

		for _, item := range items {


		authMigrationsDir := "packages/db/pkg/auth/migrations"

		db.ApplyMigrationsUpTo(t, 20260401000001, authMigrationsDir)

	AuthUserSyncBackgroundWorkerEnabled bool `env:"AUTH_USER_SYNC_BACKGROUND_WORKER_ENABLED" envDefault:"false"`
	EnableAuthUserSyncBackgroundWorker bool `env:"ENABLE_AUTH_USER_SYNC_BACKGROUND_WORKER" envDefault:"false"`

Conversation

ben-fornefeld commented Mar 28, 2026

Uh oh!

cursor bot commented Mar 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

Uh oh!

claude bot Mar 28, 2026

Choose a reason for hiding this comment

Uh oh!

claude bot Mar 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

chatgpt-codex-connector bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

claude bot Apr 1, 2026

Choose a reason for hiding this comment

What the bug is and how it manifests

The specific code path that triggers it

Why existing code does not prevent it

Impact

How to fix it

Step-by-step proof

Uh oh!

Choose a reason for hiding this comment

Uh oh!

claude bot Apr 1, 2026

Choose a reason for hiding this comment

What the bug is and how it manifests

The specific code path that triggers it

Why existing code does not prevent it

What the impact would be

How to fix it

Step-by-step proof

Uh oh!

dobrac left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cursor bot commented Mar 28, 2026 •

edited

Loading