# LXMF 1.1.0: Missing propagation-peer path causes synchronization attempts every 24 seconds without backoff

_General · started by nilu96 on Thu, Jul 30, 2026 12:12 AM_

---

## Original post

**nilu96** · Thu, Jul 30, 2026 12:12 AM

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.

---

## Reply 1

**Mark** · Thu, Jul 30, 2026 11:34 AM

That's definitely an oversight. Fixed in `c939e253614d63601240456032e972bd3ab347f2`.

---

## Reply 2

**nilu96** · Thu, Jul 30, 2026 7:26 PM

Thanks a lot, that was quick!

---