Skip to content

Fix migration 131 on installs where 094 left automation_folders behind - #4

Merged
sathyaprakash000 merged 1 commit into
mainfrom
claude/fix-131-folder-fk
Oct 18, 2026
Merged

sathyaprakash000 merged 1 commit into
mainfrom
claude/fix-131-folder-fk

Conversation

@sathyaprakash000

Copy link
Copy Markdown
Contributor

Migration 131_remove_forms_projects fails on an upgraded install where migration 094 couldn't rename automation_folders, because projects had already been created at boot. chatbots.folder_id still has a foreign key to the old table, so DROP TABLE errors, the migration runner stops and the backend crash-loops.

This drops the unused folder_id column before dropping the table. Found while deploying #3 to the demo install. Tested on a restored copy of that database: 131–134 apply cleanly, and 131 re-runs without errors.

🤖 Generated with Claude Code

On an install whose boot-time ensureProjectTables() created `projects` before
migration 094 ran, 094 could not rename automation_folders and left it in place
with chatbots.folder_id still pointing at it. 131's DROP TABLE then failed on that
foreign key, the migration runner stopped, and the backend crash-looped. Drop the
unused folder_id column first. Found deploying the previous release to the demo.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sathyaprakash000
sathyaprakash000 merged commit 6380977 into main Oct 18, 2026
8 of 9 checks passed
@sathyaprakash000
sathyaprakash000 deleted the claude/fix-131-folder-fk branch October 18, 2026 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant