fix(db): remove orphaned agent_schedules migration - #29
Conversation
Migration 0045_agent_schedules_notify_on.sql references a table that was never created — no CREATE TABLE migration or schema.ts definition for agent_schedules exists anywhere in history. This breaks migrations on every fresh install. Fixes #1351
raghavyuva
left a comment
There was a problem hiding this comment.
Thanks for digging into this @vivekbhat07 — the fresh-install diagnosis is correct: agent_schedules has no CREATE TABLE anywhere in this repo's migrations or schema.ts, migration 0045 is journaled, and drizzle-kit migrate runs on every container start (scripts/entrypoint.js), so ALTER TABLE "agent_schedules" does fail on a fresh database (IF NOT EXISTS only guards the column, not the table).
However, deleting the migration is the wrong remedy — it regresses an intentional fix. Requesting changes for the reasons below.
1. agent_schedules is a Go-API table in the shared database; 0045 was deliberate
Commit efaa733 (which added 0045) says: "Aligns Supabase schema with the API scheduler model so due-schedule queries stop failing." And commit 42b9a39 documents the architecture: "The Go API creates agent_threads/agent_messages" in the same database this service migrates. agent_schedules follows that same pattern — it exists in deployed shared DBs even though no migration here creates it, and the notify_on column fixed real scheduler query failures.
Deleting 0045 means any deployment that hasn't applied it yet (and every fresh install once the Go API creates the table) never gets notify_on, and the column "notify_on" does not exist failures come back.
Suggested fix — keep the migration and its journal entry, and guard it the same way 42b9a39 fixed 0044 for exactly this class of problem:
DO $$ BEGIN
IF to_regclass('public.agent_schedules') IS NOT NULL THEN
ALTER TABLE "agent_schedules" ADD COLUMN IF NOT EXISTS "notify_on" text DEFAULT 'smart' NOT NULL;
END IF;
END $$;This is a no-op on fresh DBs (fixing the install breakage) while preserving the column-add where the Go API owns the table.
2. Undisclosed deletion of drizzle/0027_dollar_based_credits.sql
The PR description only mentions 0045, but the diff also removes this file. It does appear to be a harmless orphan (never journaled — the journaled 0027 is 0027_silent_moondragon — and nothing executes un-journaled .sql files), but please either mention it in the description or split it into its own cleanup PR. Note the same logic applies to drizzle/0041_nappy_omega_sentinel.sql (also un-journaled, and the only DDL creating cli_installations, which schema.ts still declares) — if we're cleaning up orphans, that one needs a decision too, ideally in the same follow-up.
3. Broken issue reference
"Fixes #1351" points at an issue that doesn't exist in this repo (404). If it refers to the main Nixopus repo's tracker, please use the full nixopus/nixopus#1351 form or drop it.
Happy to re-review once the guarded version of 0045 is in place.
Generated by Claude Code
…ce check agent_schedules is created by the Go API in the shared database, not by this service's migrations. Guard the ALTER with to_regclass() so it's a no-op on fresh installs where the table doesn't exist yet, while still adding notify_on where the Go API has already created the table. Restores 0027_dollar_based_credits.sql (unrelated orphan, out of scope for this fix, per review feedback).
|
Thanks for the catch — didn't realize agent_schedules was owned by the Go API. Pushed the guarded version using to_regclass() as suggested, and restored 0027_dollar_based_credits.sql (confirmed via diff it's byte-identical to what was there before, unrelated to this fix). For the issue reference, it should be nixopus/nixopus#1351 — updating the PR description now. |
Migration 0045_agent_schedules_notify_on.sql references a table that was never created — no CREATE TABLE migration or schema.ts definition for agent_schedules exists anywhere in history. This breaks migrations on every fresh install.
Fixes #1351