Skip to content

fix: use table recreation for sub_agent_skills unique constraint migration #2208

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
amikofalvy wants to merge 1 commit into from
Closed

fix: use table recreation for sub_agent_skills unique constraint migration #2208

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 20 additions & 2 deletions packages/agents-core/drizzle/manage/0010_oval_angel.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,2 +1,20 @@
ALTER TABLE "sub_agent_skills" DROP CONSTRAINT "sub_agent_skills_sub_agent_skill_unique";--> statement-breakpoint
ALTER TABLE "sub_agent_skills" ADD CONSTRAINT "sub_agent_skills_sub_agent_skill_unique" UNIQUE("tenant_id","project_id","agent_id","sub_agent_id","skill_id");
CREATE TABLE "sub_agent_skills_new" (
"tenant_id" varchar(256) NOT NULL,
"id" varchar(256) NOT NULL,
"project_id" varchar(256) NOT NULL,
"agent_id" varchar(256) NOT NULL,
"sub_agent_id" varchar(256) NOT NULL,
"skill_id" varchar(64) NOT NULL,
"index" numeric DEFAULT 0 NOT NULL,
"always_loaded" boolean DEFAULT false NOT NULL,
"created_at" timestamp DEFAULT now() NOT NULL,
"updated_at" timestamp DEFAULT now() NOT NULL,
CONSTRAINT "sub_agent_skills_tenant_id_project_id_agent_id_id_pk" PRIMARY KEY("tenant_id","project_id","agent_id","id"),
CONSTRAINT "sub_agent_skills_sub_agent_skill_unique" UNIQUE("tenant_id","project_id","agent_id","sub_agent_id","skill_id")
);--> statement-breakpoint
INSERT INTO "sub_agent_skills_new" SELECT * FROM "sub_agent_skills";--> statement-breakpoint
DROP TABLE "sub_agent_skills";--> statement-breakpoint
ALTER TABLE "sub_agent_skills_new" RENAME TO "sub_agent_skills";--> statement-breakpoint
ALTER TABLE "sub_agent_skills" ADD CONSTRAINT "sub_agent_skills_sub_agent_fk" FOREIGN KEY ("tenant_id","project_id","agent_id","sub_agent_id") REFERENCES "public"."sub_agents"("tenant_id","project_id","agent_id","id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
ALTER TABLE "sub_agent_skills" ADD CONSTRAINT "sub_agent_skills_skill_fk" FOREIGN KEY ("tenant_id","project_id","skill_id") REFERENCES "public"."skills"("tenant_id","project_id","id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
CREATE INDEX "sub_agent_skills_skill_idx" ON "sub_agent_skills" USING btree ("skill_id");
Comment on lines +1 to +20
Copy link
Contributor

@claude claude bot Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 CRITICAL: Editing an already-applied migration file

Issue: This PR modifies 0010_oval_angel.sql, an existing migration file that already exists on main (introduced in PR #2190, reverted in #2205, re-reverted in #2207). Per AGENTS.md line 147: "NEVER edit existing migration SQL files after they've been applied — create new migrations instead."

Why: Drizzle tracks applied migrations by filename in drizzle.__drizzle_migrations. When the migration file content changes but the filename stays the same:

  • Databases where 0010 already ran will not re-run the new SQL (migration marked as "applied")
  • Those databases will have inconsistent schema state (either the old constraint columns if it succeeded, or a broken state if the original Doltgres limitation caused it to fail)
  • New databases will get the correct table recreation approach, causing schema drift between environments

Fix: Create a new migration file (e.g., 0011_fix_sub_agent_skills_constraint.sql) that:

  1. Applies the table recreation pattern for databases that need it
  2. Is idempotent (safe to run on databases in any state)

Example approach:

-- 0011_fix_sub_agent_skills_constraint.sql
-- Check if we need to apply the fix (constraint doesn't have all 5 columns)
-- Then apply table recreation pattern

Alternatively, if you're certain migration 0010 has never been successfully applied to any environment (failed everywhere due to Doltgres limitation), document that assumption clearly and consider whether the rollback strategy is acceptable.

Refs:

Loading