[HanielUlises]

A fleet that stops answering is not the same thing as a fleet that has stopped, and until now the experiment could only produce the second. run.sh kills the adapter; it comes back believing its robots are at their chargers, so every task it accepts afterwards never finishes, and a mission that replans into that is not recovering from an interruption — it is failing against a different fleet.

Publishing false on /eplansys/rmf_link drops what arrives over the websocket from then on. The socket stays up, the frames are still counted, the requests still go out, and what is lost is the road back. true reads it again. Both transitions are logged by the bridge.

What it shows

experiments/oe4-desconexion/run-corte-reversible.sh, cut at 10 s into the drive, 20 s of outage, bridge waiting 30 s:

the link with the fleet is down; the fleet is not, and what it says from here on is dropped
goto_site: 0 of 1 RMF task(s) done after 30s, last underway
(goto_site scout):0 failed: RMF task timed out
the policy failed; replanning from the state the mission reached
the link with the fleet is up again; what it says from here on is read
planning (attempt 2 of 3)
mission complete

ok   (Kw scout contaminated) holds
ok   (Kw relay contaminated) holds
ok   (Kw observer contaminated) does not hold
ok   somebody on the team was spoken to: relay
ok   observer was spoken to by nobody

The first attempt dies because what the fleet said was dropped on arrival. The second plans from the state the mission reached, submits a fresh task to a fleet that never went away, and finishes. Five of five.

The check that had to change with it

mission_check gains heard_any, and the one-site launch asks with it instead of naming scout. Which team member goes to the site and which is told is the planner's choice — relay-dirty_relay_scout and relay-dirty_scout_relay both answer the goal — and a replan from a different state picked the other one, failing a mission that had succeeded. What the mission claims is that the finding reached the team over a channel the observer was not on, and that is now what is checked.

heard_something keeps working and its default is now empty, since which agent is spoken to belongs to a launch rather than to the node.

Checked

• the reversible outage run above, five of five
• the two-site fleet mission unchanged by this: 52.3 s, eight of eight, both robots still driving together
• linters clean over the three packages