fix(store): cast entity id to bytea in FindPossibleDeletionsQuery UNION - #6709
Open
SnowingFox wants to merge 1 commit into
Open
fix(store): cast entity id to bytea in FindPossibleDeletionsQuery UNION#6709SnowingFox wants to merge 1 commit into
SnowingFox wants to merge 1 commit into
Conversation
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
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.
Summary
Fixes #6695 -
entityChangesInBlockfails withUNION types bytea and text cannot be matchedon deployments whose entity types use different ID types (someBytes, someString/ID).Root cause
FindPossibleDeletionsQuery(store/postgres/src/relational_queries.rs) builds oneUNION ALLstatement per deployment with one branch per entity table:e.idis selected raw, so its column type follows the entity:textforID/Stringids andbyteaforBytesids (andint8forInt8ids).UNION ALLrequires a common type per column position, so any schema mixingtextandbyteaids is rejected by Postgres before a single row is read.This is the same class of bug that
FindRangeQueryalready guards against - itswalk_astselects the id through a per-type cast (id::bytea/id/id::text::byteavia thematch pk_column.column_typeblock).FindPossibleDeletionsQuerynever got the same treatment.The fix
Mirror
FindRangeQuery: select the primary-key column through a per-type cast so every branch of theUNION ALLproduces abyteaid column:String/IDe.id::byteaBytese.idInt8e.id::text::byteae.id::byteaOnly the deletions query is affected.
FindChangesQueryselectsto_jsonb(e.*)(alwaysjsonb), which is why it never trips on this error.Test
Adds
find_possible_deletions_query_id_type_castingtostore/postgres/src/relational/query_tests.rs(alongside the existingfind_range_query_id_type_casting). It builds layouts withString,Bytes, andInt8ids, rendersFindPossibleDeletionsQueryfor each id type individually and combined, and asserts the id column carries the correct cast so theUNION ALLbranches share a commonbyteatype. On the pre-fix code the test fails (no cast emitted); on the fixed code it passes.Impact
Read-only query path (
entityChangesInBlock->SubgraphStore::entity_changes_in_block->DeploymentStore::get_changes->Layout::find_changes). Indexing and query serving are unaffected.