[9thLevelSoftware]

What

• .supabase-cli-version: 2.117.0 → 2.122.0
• src/lib/database.types.ts: regenerated with 2.122.0 (db reset --no-seed, then gen:types:local)
• deploy-edge-functions.yml: header comment names the new pin

Generator output changes in 2.122.0

• Every table gains ComputedFields: never.
• NOT NULL json/jsonb columns become NonNullable<Json>.
• Generated columns become never in Insert/Update.

Checked locally

• npm run typecheck: no new errors (app 21/21 known, test 139/139 known)
• npm test: 2486 passed, 16 skipped
• npm run check:edge-functions: clean
• migration list --output-format json on 2.122.0 has the same shape; scripts/migration-list-applied.mjs parses it (156/156 applied on a fresh stack)

After merge

Per the deploy-edge-functions.yml header, the first deploy on a new CLI is the first real run of its bundling and upload path. Watch that run and smoke-test one function afterwards.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[kilo-code-bot]

SUGGESTION: Header duplicates the pinned CLI version

.supabase-cli-version is already the single source for the CLI version, and the other three workflows that read it (migrations.yml, edge-integration.yml, prod-migration-drift.yml) say only "the repo-wide pin in .supabase-cli-version". This header is the single place that hardcodes the number, so every CLI bump has to hand-edit it — this PR is the proof — and a forgotten edit leaves a wrong version in the prod-deploy header. Drop the parenthetical version and keep the pointer to the file.

Optional cleanup; the current value is correct.

[kilo-code-bot]

SUGGESTION: Two other places still describe 2.117.0 as the pinned CLI

tests/ci/migration-list-applied.test.ts:7 says the JSON fixtures were captured "on the pinned CLI (2.117.0)", which is false after this bump (2.117.0 is the previous pin), and docs/runbooks/operations.md:1672 records supabase secrets set --help as "verified against CLI 2.117.0". Reword the test comment to name 2.117.0 as the version the fixtures came from (or re-capture them on 2.122.0), and re-check the --env-file flag on the new CLI before the next shared-cron-secret rotation.

Non-blocking: the parser fails closed on a shape change, so the deploy gate is still safe.

[kilo-code-bot]

SUGGESTION: NonNullable<Json> also removes the JSON value null

analytics_percentiles.percentile_values is JSONB NOT NULL DEFAULT '{}' (20260318150000), which rejects SQL NULL but still accepts the JSON value null ('null'::jsonb). The new NonNullable<Json> drops null from the union, so TS can no longer express that value and a row holding JSON null is typed as non-null. Same shape now applies to equipment_rack, led_preferences, vbt_preferences, workout_preferences, payload, row_snapshot, result and dismissed_hints.

No current impact — nothing writes JSON null to those columns — so this is optional. If it must stay representable, correct it in src/lib/database.ts, which is the file reserved for generator fixes, not in this generated one.

[kilo-code-bot]

Code Review Summary

Status: 4 Issues Found | Recommendation: Merge — all four findings are optional cleanup

Verdict

Comment only — the new pgTAP arbiter fix is correct for the pinned CLI's storage shape and nothing in this PR blocks the merge; the four findings below are documentation/cleanup only.

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	4

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
supabase/tests/database/storage_avatars.test.sql	34	New comment hardcodes "Supabase CLI 2.122.0 (storage-api v1.84.19)"; .supabase-cli-version is the pin, so the line goes stale on the next bump
.github/workflows/deploy-edge-functions.yml	32	Header hardcodes the CLI version, duplicating .supabase-cli-version; it needs a hand-edit on every bump and no other workflow hardcodes it
.supabase-cli-version	1	tests/ci/migration-list-applied.test.ts:7 still calls the 2.117.0 fixture capture "the pinned CLI"; docs/runbooks/operations.md:1672 verifies secrets set --help against 2.117.0 only
src/lib/database.types.ts	96	NonNullable<Json> forbids the JSON value null, which a NOT NULL jsonb column still accepts ('null'::jsonb); no current impact, but src/lib/database.ts is the repo's designated place to correct generator output

Correctness / Safety Findings

No correctness or safety findings.

The new commit (87093c1) touches only supabase/tests/database/storage_avatars.test.sql: the four avatar upserts now name the partial unique index as the arbiter (ON CONFLICT (bucket_id, name) WHERE archived_at IS NULL DO UPDATE). That is the correct form for storage.idx_objects_current_version — PostgreSQL's inference accepts a column list plus the index predicate, and the predicate matches the partial index exactly, so a bare (bucket_id, name) really does have no arbiter once storage-api dropped bucketid_objname. The conflict set is unchanged (no statement in the file sets archived_at, so every conflicting row is archived_at IS NULL), which means the RLS paths are untouched, the hijack upsert still fails with the expected 42501, and the count = 1 assertions still hold. The pgTAP suite does run for this PR — supabase/tests/** is in the migrations.yml pull_request path filter, and that job starts a fresh stack from the pinned CLI — so a wrong predicate would fail loudly with 42P10 in CI rather than pass silently.

Assumption stated for the record: this sandbox has no network access, so the comment's upstream claims (storage-api migration 0072, storage-api v1.84.19, "hosted projects already run that migration") could not be verified against the storage repo; the functional change itself was verified against the repo's own SQL, the pinned-CLI CI path, and the fact that the bare arbiter form failed before the bump. The three carried-forward findings were re-checked against current HEAD and are unchanged.

Ponytail Review

supabase/tests/database/storage_avatars.test.sql:L29: shrink: seven-line rationale comment where three lines carry the same information. Keep the index name, the predicate and the 42P10 symptom; drop the migration number, the CLI/storage-api versions and the "older local shape" sentence.

supabase/tests/database/storage_avatars.test.sql:L34: delete: "Supabase CLI 2.122.0 (storage-api v1.84.19)" duplicates the pin in .supabase-cli-version and needs a manual edit on every bump. Point at the pinned CLI instead, as migrations.yml, edge-integration.yml and prod-migration-drift.yml do.

.github/workflows/deploy-edge-functions.yml:L32: delete: "(currently 2.122.0)" duplicates the pin in .supabase-cli-version and needs a manual edit on every bump. Keep the pointer to the file, as migrations.yml, edge-integration.yml and prod-migration-drift.yml do.

Ponytail net: -4 lines.

Suggested Minimal Patch

Optional, four small edits, no new dependencies:

1. supabase/tests/database/storage_avatars.test.sql:29-35 — trim the comment to three lines and drop the version numbers.
2. .github/workflows/deploy-edge-functions.yml:32 — drop "(currently 2.122.0)".
3. tests/ci/migration-list-applied.test.ts:7 — say "on CLI 2.117.0 (previous pin)" instead of "the pinned CLI (2.117.0)"; re-check supabase secrets set --env-file on 2.122.0 before the next shared-cron-secret rotation.
4. src/lib/database.types.ts — leave the generated file alone; if the JSON null value must stay representable, add the override in src/lib/database.ts.

Final Merge Guidance

Can merge as-is; the four suggestions are optional cleanup.

Two notes for the operator. The PR body still describes only the CLI bump and the type regeneration — it does not mention the pgTAP arbiter fix, and the DB suite now depends on the storage-api shape that ships with the pinned CLI. And this PR edits .github/workflows/deploy-edge-functions.yml, which is on that workflow's own push path filter, so merging to main triggers a full Edge Function deploy with the new CLI; the header's "watch that run" instruction applies to this merge.

Files Reviewed (4 files)

• supabase/tests/database/storage_avatars.test.sql - 1 issue
• .github/workflows/deploy-edge-functions.yml - 1 issue
• .supabase-cli-version - 1 issue
• src/lib/database.types.ts - 1 issue

Fix these issues in Kilo Cloud

Previous Review Summary (commit 76a29b2)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 76a29b2)

Status: 3 Issues Found | Recommendation: Merge — all three findings are optional cleanup

Verdict

Comment only — the regenerated types match the migrated schema and the CLI pin stays wired through the single-source pin file, so nothing blocks the merge; the three findings below are documentation/cleanup only.

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	3

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
.github/workflows/deploy-edge-functions.yml	32	Header hardcodes the CLI version, duplicating .supabase-cli-version; it needs a hand-edit on every bump (this PR) and no other workflow hardcodes it
.supabase-cli-version	1	tests/ci/migration-list-applied.test.ts:7 still calls the 2.117.0 fixture capture "the pinned CLI"; docs/runbooks/operations.md:1672 verifies secrets set --help against 2.117.0 only
src/lib/database.types.ts	96	NonNullable<Json> forbids the JSON value null, which a NOT NULL jsonb column still accepts ('null'::jsonb); no current impact, but src/lib/database.ts is the repo's designated place to correct generator output

Correctness / Safety Findings

No correctness or safety findings.

Verified against the schema while reviewing: profiles.user_id and local_profile_preferences.updated_at are GENERATED ALWAYS columns, so never in Insert/Update is correct; public_profiles.id and creator_stats.user_id trace to profiles.id (UUID PRIMARY KEY), so the drop of | null is correct; rep_telemetry gaining Insert/Update matches it being an auto-updatable view; ComputedFields: never and Args: Record<PropertyKey, never> are generator output, and migrations.yml re-runs gen:types:check byte-for-byte on this PR (.supabase-cli-version and src/lib/database.types.ts are both on its path filter). The typecheck baseline totals match the PR description exactly (app 21/21, test 139/139), and the in-repo parsers of the generated file (tests/security/helpers/migrationSchema.ts, src/lib/__tests__/parity-pull-rpc-args.test.ts) are unaffected by the new ComputedFields / NonNullable<Json> shapes.

Note for the operator: this PR edits .github/workflows/deploy-edge-functions.yml, which is on that workflow's own push path filter, so merging to main triggers a full Edge Function deploy with the new CLI — the header's "watch that run" instruction applies to this merge.

Ponytail Review

.github/workflows/deploy-edge-functions.yml:L32: delete: "(currently 2.122.0)" duplicates the pin in .supabase-cli-version and needs a manual edit on every bump. Keep the pointer to the file, as migrations.yml, edge-integration.yml and prod-migration-drift.yml do.

Ponytail net: 0 lines.

Suggested Minimal Patch

Optional, three small edits, no new dependencies:

1. .github/workflows/deploy-edge-functions.yml:32 — drop "(currently 2.122.0)".
2. tests/ci/migration-list-applied.test.ts:7 — say "on CLI 2.117.0 (previous pin)" instead of "the pinned CLI (2.117.0)"; re-check supabase secrets set --env-file on 2.122.0 before the next secret rotation.
3. src/lib/database.types.ts — leave the generated file alone; if the JSON null value must stay representable, add the override in src/lib/database.ts.

Final Merge Guidance

Can merge as-is; the three suggestions are optional cleanup.

Files Reviewed (3 files)

• .github/workflows/deploy-edge-functions.yml - 1 issue
• .supabase-cli-version - 1 issue
• src/lib/database.types.ts - 1 issue

Fix these issues in Kilo Cloud

---

_{Reviewed by minimax-m3 · Input: 70.5K · Output: 32.8K · Cached: 886.4K}

_{Review guidance: REVIEW.md from base branch main}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	phoenix-portal	87093c1	Commit Preview URL Branch Preview URL	Oct 27 2026, 03:11 PM

[kilo-code-bot]

SUGGESTION: Comment hardcodes the CLI version that .supabase-cli-version owns

Supabase CLI 2.122.0 here duplicates the version that .supabase-cli-version is the single source for, so this line needs a hand-edit on the next bump - the same duplication already flagged on .github/workflows/deploy-edge-functions.yml:32. The storage-api v1.84.19 version rots the same way.

Optional cleanup; the statement itself is correct. Point at the pinned CLI instead:

Suggested change

	-- the local stack has it from Supabase CLI 2.122.0 (storage-api v1.84.19). The
	-- the local stack has it from the storage-api that ships with the pinned CLI; the