[High][Correctness] Message try_duration is ignored by the retransmission loop #29
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Outbound messages accept a caller-provided
try_duration, but the background retransmission loop does not use it. Instead, the loop always uses the fixedMESSAGE_SEND_WINDOWconstant.Why this matters
The API contract says callers can control how long the system should keep trying to send a message. That contract is currently false.
This affects:
Evidence
The requested deadline is computed and stored here:
mycelium/src/message.rs:982-989But the spawned retransmission loop uses:
mycelium/src/message.rs:1031-1033Specifically, it creates
tokio::time::interval(MESSAGE_SEND_WINDOW)instead of using the per-message deadline ortry_duration.There is also a secondary consistency problem where socket-forwarded replies reuse the same fixed window at:
mycelium/src/message.rs:620-624Expected behavior
The retransmission/abort logic should honor the requested deadline for each message.
Actual behavior
Messages are governed by a fixed 5-minute send window regardless of the requested duration.
Suggested fix
sleep_untilderived from the message-specific deadline.try_durationvalues behave differently.Risk
High correctness/API-contract issue. It makes timeout behavior unpredictable for callers and can cause messages to be retried far longer than requested.