Skip to content

feat(kaspa): add migration lock file for escrow config safety#453

Merged
danwt merged 1 commit intomain-dymfrom
danwt/claude/migration-lock-file
Jan 26, 2026
Merged

feat(kaspa): add migration lock file for escrow config safety#453
danwt merged 1 commit intomain-dymfrom
danwt/claude/migration-lock-file

Conversation

@danwt
Copy link
Copy Markdown

@danwt danwt commented Jan 26, 2026

Summary

Adds a local lock file mechanism to prevent operators from running with stale escrow config after migration.

How It Works

Migration mode startup:

  • Writes kaspa_migration.lock to the db directory
  • File contains the migration target (new escrow address)

Normal mode startup:

  • If lock file exists AND configured escrow matches → delete lock, continue
  • If lock file exists AND configured escrow mismatches → panic with clear error message
  • If no lock file → continue (never migrated, or operator manually deleted)

Example Error

Escrow configuration mismatch after migration!
Lock file: /path/to/kaspa_migration.lock
Expected escrow (from migration): kaspatest:pqnew...
Configured escrow: kaspatest:pqold...

Please update kaspaValidatorsEscrow in your config to: kaspatest:pqnew...
Or if you're sure your config is correct, delete the lock file manually.

Why This Approach

The previous approach (PR #441, reverted in #452) queried old Kaspa transactions via REST API to verify escrow config. This failed because:

  • api-tn10.kaspa.org returns 500 for all queries
  • rest.tn.kaspa.rollapp.network returns 404 for old/pruned transactions

A local lock file has no external dependencies and is reliable.

Test plan

  • cargo check -p validator passes
  • Manual testing on blumbus

🤖 Generated with Claude Code

When a validator enters migration mode, it writes a lock file containing
the migration target (new escrow address). When the validator later starts
in normal mode, it verifies the configured escrow matches the lock file.

This prevents operators from forgetting to update their escrow config
after a migration completes. The lock file serves as a reminder that must
be resolved (either by updating config or manually deleting the file).

Lock file behavior:
- Migration mode: writes `kaspa_migration.lock` with new escrow address
- Normal mode + lock exists + escrow matches: deletes lock, continues
- Normal mode + lock exists + escrow mismatch: panics with clear error
- Normal mode + no lock: continues (never migrated or manually cleared)

This replaces the previous approach (PR #441) which queried old Kaspa
transactions via REST API - those queries are unreliable for old/pruned TXs.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@danwt danwt merged commit d536c0b into main-dym Jan 26, 2026
7 of 11 checks passed
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