mirror of
https://github.com/0xWheatyz/handler.git
synced 2026-08-30 03:31:36 +00:00
Claude
43e1fa3619
Removing a repo returned 500. `delete_project` deleted only the projects row, but `commands`, `agents`, `approvals`, and `schedules` all carry a foreign key to `projects.id` with no ON DELETE CASCADE — and every real project has at least the `sync` command queued at registration referencing it, so Postgres rejected the delete with a ForeignKeyViolation (commands_project_id_fkey). The existing tests only deleted dependent-free projects, so it went unnoticed (and SQLite, though it has FK enforcement on here, was never exercised with a referencing row). delete_project now clears dependents in FK-safe order: agent-owned rows (checkmarks before log_entries per the use_alter cycle, approvals authored by those agents, and shared_context attribution nulled since it's a global table), then schedules (which reference commands via last_command_id), then the project-scoped approvals/commands/agents, then the project. delete_agent had the same latent bug — a spawned agent always accrues a checkmark + log entries via the hooks, which the log_entries/checkmarks FKs would block — so it shares the same _purge_agent_dependents helper. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BxKY28XKCM6o4ag3nmaVsZ