fix: Resolve database migration failure on existing databases

Fixes critical issue where migration 002 indexes already existed in SCHEMA_SQL,
causing 'index already exists' errors on databases created before v1.0.0-rc.1.

Changes:
- Removed duplicate index definitions from SCHEMA_SQL (database.py)
- Enhanced migration system to detect and handle indexes properly
- Added comprehensive documentation of the fix

Version bumped to 1.0.0-rc.2 with full changelog entry.

Refs: docs/reports/2025-11-24-migration-fix-v1.0.0-rc.2.md
This commit is contained in:
2025-11-24 13:11:14 -07:00
parent 89758fd1a5
commit 3ed77fd45f
16 changed files with 2723 additions and 18 deletions

View File

@@ -7,6 +7,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
## [1.0.0-rc.2] - 2025-11-24
### Fixed
- **CRITICAL: Database migration failure on existing databases**: Removed duplicate index definitions from SCHEMA_SQL
- Migration 002 creates indexes `idx_tokens_hash`, `idx_tokens_me`, and `idx_tokens_expires`
- These same indexes were also in SCHEMA_SQL (database.py lines 58-60)
- When applying migration 002 to existing databases, indexes already existed from SCHEMA_SQL, causing failure
- Removed the three index creation statements from SCHEMA_SQL to prevent conflicts
- Migration 002 is now the sole source of truth for token table indexes
- Fixes "index already exists" error when running migrations on databases created before v1.0.0-rc.1
### Technical Details
- Affected databases: Any database created with v1.0.0-rc.1 or earlier that had run init_db()
- Root cause: SCHEMA_SQL ran on every init_db() call, creating indexes before migration could run
- Solution: Remove index creation from SCHEMA_SQL, delegate to migration 002 exclusively
- Backwards compatibility: Fresh databases will get indexes from migration 002 automatically
## [1.0.0-rc.1] - 2025-11-24
### Release Candidate for V1.0.0