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

1. A Supabase phone-only user signs up. The auth.users row has id = <uuid>, email = NULL.
2. The sync_insert_auth_users_to_public_users_trigger fires, inserting (user_id, 'upsert') into public.user_sync_queue.
3. The worker calls ClaimBatch, picks up the item, increments attempt_count to 1.
4. processor.process() -> processOnce() -> reconcile() -> store.GetAuthUser(ctx, userID).
5. 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.
6. Back in reconcile(), errors.Is(err, pgx.ErrNoRows) is false. The error is returned as fmt.Errorf("get auth.users %s: %w", ...).
7. process() sees item.AttemptCount (1) < maxAttempts (20), so it calls store.Retry(...) with a 5s backoff.
8. Steps 3-7 repeat until attempt_count >= 20, at which point DeadLetter is called.
9. The user is now dead-lettered and will never be synced to public.users.

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

1. Operator sets DASHBOARD_API_ENV_VARS='{"DB_URL":"postgresql://user:p\"ass@host/db"}' in their env file.
2. Terraform receives var.dashboard_api_env_vars = {DB_URL = "postgresql://user:p\"ass@host/db"}.
3. local.env passes it through unchanged (non-null, non-empty).
4. templatefile() renders line 87 as: DB_URL = "postgresql://user:p"ass@host/db" -- the embedded " terminates the HCL string prematurely.
5. Nomad's job spec parser receives invalid HCL and rejects the job with a parse error.
6. 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.