Problem
The legacy 4.9 upgrade path in mactrack_database_upgrade() inspects SHOW INDEXES into $keys, then compares the array directly with the integer 7. That condition does not test the index count and causes the rebuild path to run whenever this migration is reached.
The rebuild also recreates port_number as a non-unique index, while the fresh schema declares it unique and poller writes rely on ON DUPLICATE KEY UPDATE. This leaves upgraded installations with semantics that differ from new installations.
Required validation
- Reproduce from representative pre-4.9 schemas and data in both MariaDB and MySQL Docker containers.
- Include duplicate and mixed-format aggregated-port rows.
- Define deterministic deduplication that preserves count and date fields.
- Make the migration restartable and test interruption/failure behavior.
- Minimize index-unavailable time and fail closed if the unique postcondition cannot be established.
- Verify the resulting index definition matches the fresh schema and that poller upserts retain their expected behavior.
Scope note
This was found while reviewing the cohesive test-suite work for #357. It should not be folded into that release PR without the legacy-data and interruption coverage above.
Problem
The legacy 4.9 upgrade path in
mactrack_database_upgrade()inspectsSHOW INDEXESinto$keys, then compares the array directly with the integer7. That condition does not test the index count and causes the rebuild path to run whenever this migration is reached.The rebuild also recreates
port_numberas a non-unique index, while the fresh schema declares it unique and poller writes rely onON DUPLICATE KEY UPDATE. This leaves upgraded installations with semantics that differ from new installations.Required validation
Scope note
This was found while reviewing the cohesive test-suite work for #357. It should not be folded into that release PR without the legacy-data and interruption coverage above.