Details
Description
Environment:
indy-node 1.6.558
libindy 1.6.1~655
Steps to Reproduce:
1. Setup the docker pool of 7 nodes.
2. On one of the nodes (node 5) block the Primary (node 1) IP:
iptables -A INPUT -s 10.0.0.2 -j DROP
3. Check nodes logs.
=> Only 1 INSTANCE_CHANGE{'viewNo': 1, 'reason': 25} was send by Node5, but one more INSTANCE_CHANGE{'viewNo': 1, 'reason': 26} was send by Node7.
4. Unblock the Primary IP:
iptables -D INPUT -s 10.0.0.2 -j DROP
5. Send several txns.
Actual Results:
Node5 sends INSTANCE_CHANGE{'viewNo': 1, 'reason': 25} after each txn sending even if it don't have network issues in connection to Primary. New txns are not written on Node5.
Expected Results:
Node5 should work with Primary correctly, new txns should be written.
Additional Information:
After `iptables -D INPUT -s 10.0.0.2 -j DROP` primary node (node 1) was pinged from node which was disconnected before (node 5) and ping was successful, so simulated network issues were resolved.
See logs in attachment.
UPD:
After disconnection of Node5 from primary, Node5 was disconnected from the rest nodes in the pool. This behavior was caused by docker network behavior or iptables behavior in local network. So, this case should be re-tested on AWS pool in scope of confirmation testing of this ticket.
Summary was changed from "Node doesn't write txns after disconnection from primary" to "Node doesn't write txns after disconnection from the rest nodes".
Attachments
Issue Links
- relates to
-
INDY-1544 View Change should not be triggered by re-sending Primary disconnected if Primary is not disconnected anymore
-
- Complete
-