Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughA new integration test for node ID collision scenarios is added to the test suite. The test validates that subscriptions fail when duplicate identifiers are engineered on different nodes and confirms proper transactional rollback behavior. Changes
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.Comment |
Up to standards ✅🟢 Issues
|
Summary
Add a TAP test that exercises Spock's behaviour when two independently-created nodes end up sharing a
node_id. The id is currently generated locally ashash_any(name) & 0xffffatnode_createtime, with no cluster-wide coordination — so this collision is reachable in practice (cluster splits, geo-migrations, DR rehydration). The test documents what happens today, before any negotiation protocol lands.What's covered
The test creates a 2-node cluster (
node_createonly, no cross-wire), then tampers with n2's catalog to give it n1's id. Tampering navigates two FK constraints:node_interface.if_nodeidandreplication_set.set_nodeidfollow viaON UPDATE CASCADE;local_node.node_idhas no cascade and is updated manually underSET session_replication_role = replicato bypass the FK trigger. The PRIMARY KEY onspock.node(node_id)is enforced by the unique index, so this works only because we tamper pre-attach when each catalog still holds a single row.With the colliding state in place,
sub_createis attempted from both directions. The test asserts:duplicate key value violates unique constraint "node_pkey"(the existing PK catches the collision whencreate_node(origin)atsrc/spock_functions.c:503tries to insert the remote-rep row);spock.nodecatalogs still hold exactly one row (the failed transactions rolled back atomically);spock.subscriptionis empty on both sides (no orphan subscription rows pointing at a colliding id);sync_structure=true,sync_data=true— the PK trip has to happen before the copy phase or n2 would be left with an orphaned populated table).Out of scope
The cluster-merge case where a colliding id sits on a third-party peer (one the joining node hasn't subscribed to directly) produces silent misattribution rather than a PK trip. That requires a 3-node forwarding scenario and is left for the upcoming negotiation-protocol work.