Skip to content

fix: distinct warning for destructive table recreate (#23)#153

Open
alvarogar4 wants to merge 1 commit into
mainfrom
alvaro/chkit-recreate-warning
Open

fix: distinct warning for destructive table recreate (#23)#153
alvarogar4 wants to merge 1 commit into
mainfrom
alvaro/chkit-recreate-warning

Conversation

@alvarogar4

Copy link
Copy Markdown
Member

Summary

  • Changing engine/orderBy/primaryKey/partitionBy/uniqueKey on an existing table generates a DROP TABLE + CREATE TABLE that destroys all rows, but the drop surfaced the same generic drop_table_data_loss warning as a deliberate drop — so a user approving a "change sort key" edit lost all data with only a generic message (audit finding Fix workspace:* deps in published packages #23).
  • Detect a recreate (a drop_table whose key is also created in the same migration) and surface a distinct, louder table_recreate_data_loss warning that states all rows are deleted and the table recreated empty, and recommends migrating via a temporary table. Documented in cli/migrate.md and schema/dsl-reference.md.

Test plan

  • Unit tests (safety-markers.test.ts): recreate → table_recreate_data_loss; plain drop and drop-while-creating-a-different-table → drop_table_data_loss. Mutation-checked.
  • Live e2e (recreate-warning.e2e.test.ts): a structural change is blocked (exit 3) with the recreate warning and no data dropped.
  • typecheck + lint pass; docs site builds (30 pages).

Part of NUM-7318 (Tier-3 safety/resilience polish). 4 of 4: #23. Note: the optional auto "safe recreate" path (rename → INSERT…SELECT → drop) is intentionally deferred; this PR documents the manual safe path and makes the data loss loud.

🤖 Generated with Claude Code

Changing engine/orderBy/primaryKey/partitionBy/uniqueKey on an existing
table generates a DROP TABLE + CREATE TABLE that destroys all rows, but
the drop surfaced the same generic `drop_table_data_loss` warning as a
deliberate drop, so a user approving a "change sort key" edit lost all
data with only a generic message.

Detect a recreate (a drop_table whose key is also created in the same
migration) and surface a distinct `table_recreate_data_loss` warning
that states all rows are deleted and the table recreated empty, and
recommends migrating via a temporary table. Documented in the migrate
and schema DSL reference pages.

Verified with unit tests (mutation-checked) and a live e2e against the
ObsessionDB test cluster: a structural change is blocked with the
recreate warning and no data dropped.

Refs NUM-7318.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vs5ZySdFPLkAz33L1TEEZk
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