Fix/statusengine schema primary keys - #2
Merged
Conversation
.claude/specs/mysql_schema.sql is openITCOCKPIT's schema, not standard Statusengine's, and the PRIMARY KEYs differ: openITCOCKPIT stores a UUID in service_description, so it is unique on its own and four service tables key on it without hostname. Standard Statusengine keeps the plain description and leads those keys with hostname (setPrimaryKey in lib/mysql.php of statusengine/worker). pkColumns is what pairs a PHP row with its Go counterpart, via pkKey as a map key. On a standard installation "PING on host A" and "PING on host B" therefore produced the same key: one row silently replaced the other in the map and the comparison reported mismatches between unrelated services - noise that looks exactly like the data-parity failure this tool exists to detect. Naming hostname and service_description is a superset of openITCOCKPIT's key and exactly Statusengine's, so it is unique under both and needs no schema switch. Every one of these tables carries a hostname column in either schema, which is what makes one binary work on both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HFvRFfD1Df4LBfsNABvPPk
The ON DUPLICATE KEY UPDATE clause is a no-op because the named column is part of the PRIMARY KEY - the row only matched because every key column already holds the incoming value, so writing one of them back changes nothing. The comment and the test said "first column of the PRIMARY KEY" instead, which happens to be true of .claude/specs/mysql_schema.sql and is not the property that matters. That mattered once the dump turned out to be openITCOCKPIT's schema rather than standard Statusengine's: the two order these keys differently, so a test demanding the first column pins the fix to one schema and passes while the worker is wrong on the other. All ten declared columns are in the key under both, so no behaviour changes here - but the reason they are correct was not the reason written down. The four service tables name service_description precisely because it is the one column inside the key under both schemas. hostname reads as the natural choice from the standard-Statusengine keys and is not in openITCOCKPIT's, where it would turn every redelivered row into a real write - the mistake the test now fails on, verified by making it. Standard Statusengine's keys are transcribed beside the map rather than fetched: a test that reaches for GitHub fails offline for reasons that have nothing to do with the code under test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HFvRFfD1Df4LBfsNABvPPk
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.