# Walk through what exactly happens when a client marks its outbound raft
# transport stream as idle.

init
----

# Set up two nodes, each with one store.
add node=n1 store=s1
----

add node=n2 store=s2
----

# Send a raft message for r1 from n1 to n2 and vice versa, each node holding a
# replica with id=1,2 respectively. We do this to create the two non-idle
# client-> server connections between the two nodes, going both ways. It's done
# on demand.
send range=r1 from=n1/s1/1 to=n2/s2/2 commit=1
----

send range=r1 from=n2/s2/2 to=n1/s1/1 commit=1
----

# Verify that n1's marked n2 as something its connected to (as a client), and
# vice-versa. Ignore the connected-stores part -- it is not relevant for
# RACv2.
connection-tracker from=n1
----
connected-stores (server POV): 
connected-nodes  (client POV): n2

connection-tracker from=n2
----
connected-stores (server POV): 
connected-nodes  (client POV): n1

# Add a msg to be piggybacked from n2 back to n1.
piggyback from=n2 node=n1 store=s1 range=r1
----

# Note that it is pending.
pending-piggybacks from=n2 to=n1
----
ranges: r1

# Mark the client-initiated stream from n2->n1 as idle.
client-mark-idle from=n2 to=n1
----

# n2's wound down its transport streams and has marked n1 as something it's
# disconnected from as a client.
connection-tracker from=n2
----
connected-stores (server POV): 
connected-nodes  (client POV): 

# n1's not done the same since it still is connected to n2 as a client. We
# don't actually care about n1's perspective in this test.
connection-tracker from=n1
----
connected-stores (server POV): 
connected-nodes  (client POV): n2

# Note that it is still pending. It will only get pruned out by the periodic
# pruning process, which is invoked next.
pending-piggybacks from=n2 to=n1
----
ranges: r1

drop-disconnected-piggybacks from=n2
----

# Observe that there's nothing pending dispatch and the metrics indicate as much.
pending-piggybacks from=n2 to=n1
----
ranges: none

metrics
----
node=n1: dispatches-dropped=0
node=n2: dispatches-dropped=1
