Migrations commit schema changes even when history updates fail

Open
  • Is something wrong?
#640 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c, sqlite
Domain
database, databases

Research direction

Start with src/core/db/migrate.c, especially migrate_exec_sql() and the up/down paths at the cited lines; trace where the migration transaction ends and where _cwist_migrations is updated. Add failure-injection tests for failed history inserts and deletes, then run the migration tests. Done means a failed history write returns an error and rolls back both the schema change and its history update.

Written by the indexing model from the issue text.

Description

bug critical

Affected: dev at bb2a33946.

migrate_exec_sql() commits each up/down migration before the caller updates _cwist_migrations (src/core/db/migrate.c:40-67, src/core/db/migrate.c:142-159, and src/core/db/migrate.c:210-225). The history sqlite3_step() result is ignored and the history write is outside the migration transaction.

Reproduction:

  1. Create a trigger that raises FAIL on every insert into _cwist_migrations.
  2. Run an up migration that creates items.
  3. Observe cwist_migrate_up() return CWIST_MIGRATE_OK, items exists, but cwist_migrate_version() returns 0.

Observed: migration: rc=0 version=0 items_table=1.

A later run can reapply an already-committed migration, causing errors or destructive schema changes. Down migrations have the inverse inconsistency when the history delete fails.

Expected: execute the schema change and its history insert/delete in one transaction, check every SQLite result, and roll back both on any failure. Add failure-injection tests for up and down history writes.

Dominant language
C
Stars
16
Forks
7
Avg merge
5h 39m
Merged PRs (30d)
185

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from c4punks/CWIST

All issues in c4punks/CWIST

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.