Fix _get_server_keys_json invalidations over replication as JSON#19966
Open
erikjohnston wants to merge 2 commits into
Open
Fix _get_server_keys_json invalidations over replication as JSON#19966erikjohnston wants to merge 2 commits into
_get_server_keys_json invalidations over replication as JSON#19966erikjohnston wants to merge 2 commits into
Conversation
erikjohnston
changed the title
The cache key of `_get_server_keys_json` is a single argument which is
itself a `(server_name, key_id)` tuple, and `store_server_keys_response`
passed that nested tuple straight into the cache invalidation stream.
psycopg2 quietly serialises the inner tuple as a Postgres *record*, so the
`keys` column of `cache_invalidation_stream_by_instance` ended up holding
the record literal as a single string (e.g. `{"(srv,ed25519:abc)"}`) — which
never matches the real cache key on the receiving side, i.e. the
invalidation has always been a silent no-op on workers. The native Rust
backend's stricter parameter conversion turns the same nested tuple into a
loud `TypeError: unsupported parameter type for postgres: tuple`.
Fix it the same way #18899 did for
`_get_e2e_cross_signing_signatures_for_device`, which has the same
nested-tuple key shape: invalidate the local cache directly, JSON-encode the
key for the replication row, and decode it again in
`process_replication_rows`.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZdvuLkg7Lm7wDtPQzDnJx
erikjohnston
force-pushed
the
erikj/portdb6-pr1-storage-type-correctness
branch
from
July 15, 2026 15:04
2b4c689 to
6f02259
Compare
erikjohnston
changed the title
erikjohnston
marked this pull request as ready for review
July 16, 2026 08:45
erikjohnston
changed the title
_get_server_keys_json invalidations over replication as JSON
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
2 participants
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.
The cache key of
_get_server_keys_jsonis a single argument which is itself a(server_name, key_id)tuple, andstore_server_keys_responsepassed that nested tuple straight into the cache invalidation stream.psycopg2 quietly serialises the inner tuple as a Postgres record, so the
keyscolumn ofcache_invalidation_stream_by_instanceended up holding the record literal as a single string (e.g.{"(srv,ed25519:abc)"}) — which never matches the real cache key on the receiving side, i.e. theinvalidation has always been a silent no-op on workers. The native Rust backend's stricter parameter conversion turns the same nested tuple into a loud
TypeError: unsupported parameter type for postgres: tuple.Fix it the same way #18899 did for
_get_e2e_cross_signing_signatures_for_device, which has the same nested-tuple key shape: invalidate the local cache directly, JSON-encode the key for the replication row, and decode it again inprocess_replication_rows.Found as part of the the effort to port the database pool to Rust.