Skip to content

replicateTo update leaks to non-target node after SQL SELECT triggers cache load #211

Description

@kriszyp

Problem

Performing an update on node1 with replicateTo: [node2] (explicitly excluding node3) causes node3 to also reflect the update — but only after a SQL SELECT query is first executed against node3 with replicateFrom: false.

Steps to reproduce

  1. 3-node cluster; create a blob record id=3 replicated to all nodes
  2. Update the record on node1, targeting only node2:
    { "operation": "update", "schema": "blob", "table": "BlobTable",
      "records": [{ "id": "3", "data": null }], "replicateTo": ["127.0.0.2"] }
  3. On node3, run SQL SELECT with replicateFrom: false — observe the update appears (wrong)
  4. Then run search_by_value with replicateFrom: false — update also appears (wrong)

Expected

Node3 retains original data — it was not a replication target.

Actual

The SQL SELECT on step 3 appears to trigger a remote fetch that loads the updated value from node1/node2, polluting node3's local state. Related: CORE-2747 (same scenario without the prior SELECT causes deletion), CORE-2749 (X-Replicate-From: none not respected).

🤖 Filed by Claude on behalf of Kris.

Activity

  1. added
    bugSomething isn't working
    area:replicationReplication, cluster sync, peer connections
    from-jiraMigrated or originated from a Jira ticket
    on May 21, 2026
  2. added this to the v5.2 milestone on May 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:replicationReplication, cluster sync, peer connectionsbugSomething isn't workingfrom-jiraMigrated or originated from a Jira ticket

    Type

    No type

    Fields

    Priority

    P1

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions