Module return_path_recovery 

Sequences re-planning ahead of refilling when a return path goes silent. Sequences the response to a return path that has gone silent.

Two mechanisms react to the same evidence and, left unsequenced, work against each other. The planner learns to route around the relay that stopped delivering, while the SURB balancer floods the counterparty to refill a buffer it believes is empty. Run in the wrong order the flood mints its SURBs onto the very route the planner is in the middle of abandoning – measured at ~38 000 SURBs in 14 s against a 15 000-entry ring buffer, which is 2.5x the counterparty’s whole store, so everything older is evicted and a LIFO reader reaches preferentially for the poisoned ones.

The rule this module enforces is therefore: re-plan first, refill only if re-planning actually moved traffic. A re-plan that moves nothing means the silent relay sits on every remaining candidate – return-path diversity caps at HoprPacket::PAYLOAD_SIZE / HoprSurb::SIZE = 2, so this is an ordinary case, not a corner – and refilling then only buys more SURBs bound for the same dead route.

Structs

ReturnPathEpisodes

Tracks which destinations already have an open recovery episode.

Enums

RecoveryStep

One action taken on behalf of one destination, recorded in the order it happened.

Functions

run_flush_tick

Runs one SURB-flush tick in the exact order the flush task requires: detect, then flush, then sequence recovery.