rns.recipes

I’m seeing repeated path requests from lxmd for an unreachable LXMF propagation peer. The requests occur exactly every 24 seconds.

The scenario is:

• lxmd connects to rnsd through the local shared instance.
• The peer still has one or more unhandled_messages.
• No path exists to the peer.

LXMF’s job loop runs every four seconds and calls sync_peers() every sixth iteration, producing the observed 24-second interval. During each attempt, LXMPeer.sync():

1. Finds that no path exists.
2. Calls RNS.Transport.request_path().
3. Waits 7.5 seconds.
4. Finds that there is still no path and returns, saying it will retry later.

However, this missing-path branch does not appear to:

• increment sync_backoff;
• set next_sync_attempt;
• mark the peer unreachable; or
• otherwise make the peer temporarily ineligible for synchronization.

Consequently, the peer remains alive, idle and immediately eligible during the next 24-second scheduler pass.
LXMF already implements an incremental backoff of approximately 12 minutes per failure, but it seems to be activated only after a path exists and link establishment begins. A failed path lookup never reaches that logic.

RNS appears to be behaving correctly. It receives the request from the local lxmd shared-instance client, assigns a new request tag, and forwards the request through the other interfaces. In a transport-enabled instance, the RNS transport identity is shown as the immediate requester, although lxmd is the application-level initiator.

Would it be intended for an unreachable propagation peer with pending messages to generate a new path request every few seconds indefinitely, or is this a retry-policy gap?
My expectation would be that an unanswered path lookup counts as a synchronization failure and activates a bounded backoff—for example:

request path
wait for path timeout
if no path:
    mark peer unreachable
    increment backoff
    set next synchronization attempt
    return

A later announce, discovered path or successful link could reset the backoff.

That's definitely an oversight. Fixed in c939e253614d63601240456032e972bd3ab347f2.

Thanks a lot, that was quick!