Skip to content

fix: Host PN Sync /get-primary, fabric→Chat, and peer lifecycle #833

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rinchen merged 4 commits into from
Aug 9, 2026
Merged

fix: Host PN Sync /get-primary, fabric→Chat, and peer lifecycle #833

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d8d9057
fix: make remote PN Sync client /get-primary
rinchen Aug 9, 2026
7e11549
feat: auto-deliver Host PN fabric mail into Chat
rinchen Aug 9, 2026
c073a02
fix: restore Host PN peer lifecycle and periodic /get
rinchen Aug 9, 2026
f759a33
fix: tighten PN sync busy errors and default retrieve logging
rinchen Aug 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions docs/agents/reticulum.md
View file
Open in desktop

Large diffs are not rendered by default.

14 changes: 8 additions & 6 deletions docs/troubleshooting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1327,26 +1327,28 @@ Bond-stale **TX queue full** hints (`txQueueDropsHintBleBondStale`) point at the

**Symptoms**: Local Host propagation node is enabled but peers never hear your PN announce / cannot `/offer` or `/get`.

**Cause**: Hosting requires a live stack with identity signing key; enable starts `lxmf.propagation` LinkManager + announce loop (Resource deposit ingress + stamp validation into the local store, `/offer` admission, and outbound peer inventory sync when idle).
**Cause**: Hosting requires a live stack with identity signing key; enable starts `lxmf.propagation` LinkManager + announce loop (Resource deposit ingress + stamp validation into the local store, `/offer` admission, outbound peer inventory sync when idle, auto inbox drain into Chat, and sequenced post-peer `/get` after host `/offer` Completes).

**Fix**: Confirm sidecar is running, identity is configured, **Network → Propagation → Host propagation node** is Enabled, and check logs for `[propagation-serve]` / `[propagation-announce]` / `[propagation-deposit]`. Tune announce interval under **Advanced PN hosting**. Peers depositing to your host should see your `lxmf.propagation` hash; bad stamps are rejected and logged under `propagation-deposit`.
**Fix**: Confirm sidecar is running, identity is configured, **Network → Propagation → Host propagation node** is Enabled, and check logs for `[propagation-serve]` / `[propagation-announce]` / `[propagation-deposit]` / auto-drain / `get_post_peer` / `get_periodic`. Tune announce interval under **Advanced PN hosting**. Peers depositing to your host should see your `lxmf.propagation` hash; bad stamps are rejected and logged under `propagation-deposit`.

### Reticulum: Stored at PN but Sync leaves Chat empty

**Symptoms**: Sender shows **Stored at propagation node** (Propagated Completes). Recipient runs **Sync messages** (progress reaches Complete / HaveAll) but the DM never appears in Chat. Preferred PN hashes may differ between the two clients.

**Cause (any-node model)**: LXMF does **not** require both parties to prefer the same PN. Deposit on PN A and retrieve via Sync from PN B is valid when autopeer/static peering moves inventory. Empty Chat after Sync is usually a fabric/retrieve/ingest gap (mail never reached the synced node, stamp/admission drop on a host PN, or inbound ring not catch-up’d into Chat) — not “wrong preferred PN.”

**Progress bar ≠ retrieval.** Sync runs two independent operations against the PN: the **`/offer` peer sync** (inventory replication — this is what drives the progress bar and the `have_all`/`transfer` outcome) and the **client `/get` download** (the part that actually pulls _your_ mail into Chat). A Sync reaching **Complete / HaveAll** only tells you the peer-offer finished; it does **not** mean anything was retrieved. Look for the `/get` retrieve counts, not the peer-offer outcome.
**Progress bar = client `/get` retrieval.** User Sync against a remote PN drives the progress bar from the **client `/get` download** (inbox mail into Chat). Peer `/offer` inventory replication runs on the **local Host peer loop** when you are serving a PN — not on the Sync button — so a nonempty messagestore cannot hang Sync at AwaitingResponse against remotes that are not your peers. Look for `propagation-retrieve` `/get` Completes in Device logs for retrieve counts.

**Host PN auto Chat path:** With **Host propagation node** enabled, mail that lands in the local store via peer Resource ingress should appear in Chat via **auto-drain** (`local-prop inbox auto-drain Completes`, `retrieve_mode=local`) without pressing Sync on local-prop. After your host peer `/offer` Completes to a peered remote, a **silent** client `/get` to that peer may also run (`retrieve_mode=get_post_peer`, no Sync UI bar). While Host is on and quiet, a **~90s** periodic silent `/get` (`retrieve_mode=get_periodic`) revisits Prefer/peered remotes for inbox catch-up — this is not a 2s poll and does not re-`/offer` an unchanged store. Host peer `/offer` re-runs when the local messagestore generation advances (or after a failed/partial sync), with lxmd-style peer Idle bookkeeping. Explicit Sync remains `/get`-primary (Prefer / cascade).

**Do not** tell users they must share the same preferred PN. Prefer log correlation instead:

1. Sender Device log: `propagation-deposit` with `message_hash`, `transient_id`, `pn_hash` (deposit Completes).
2. Recipient log (the real retrieval): `propagation-retrieve … retrieve_mode=get pn_hash=… listed=N downloaded=N delivered=N` (the client `/get` download; `listed=0` is a valid empty-inbox success). Per-message `propagation-retrieve` with matching `message_hash` / `transient_id` fires as each downloaded message hits the delivery callback. `local-prop` Sync logs `retrieve_mode=local`. The peer-offer side logs `propagation-sync … peer_outcome=have_all|transfer` — that is **not** retrieval.
2. Recipient log (the real retrieval): `propagation-retrieve … retrieve_mode=get|get_post_peer|get_periodic pn_hash=… listed=N downloaded=N delivered=N` (the client `/get` download; `listed=0` is a valid empty-inbox success). Per-message `propagation-retrieve` with matching `message_hash` / `transient_id` fires as each downloaded message hits the delivery callback. Host auto-drain / `local-prop` Sync logs `retrieve_mode=local`. The peer-offer side logs `propagation-sync … peer_outcome=have_all|transfer` — that is **not** retrieval.
3. Renderer: `[catchUpRecentInboundLxmf] … reason=propagation_sync` or `propagation-retrieve catch-up after sync Completes count=N` (`count=0 (empty ring)` means Sync Completes with no new inbound for Chat).
4. Confirm remote Sync Completes and that Host PN (if used) shows `[propagation-deposit] local PN accepted stamped propagated blob`.
4. Confirm remote Sync Completes and that Host PN (if used) shows `[propagation-deposit] local PN accepted stamped propagated blob` plus auto-drain / post-peer / periodic retrieve lines when expecting Chat without a manual Sync.

**Fix**: Retry Sync after path/announce settle; if using local Host, confirm ingress logs and peer sync ticks (`local host queued outbound peer inventory sync`). Export developer bundles from both sides and `rg 'propagation-deposit|propagation-retrieve'`.
**Fix**: Retry Sync after path/announce settle; if using local Host, confirm ingress + auto-drain / silent `/get` (`get_post_peer` / `get_periodic`) logs and peer sync ticks (`local host queued outbound peer inventory sync`). Export developer bundles from both sides and `rg 'propagation-deposit|propagation-retrieve'`.

### Reticulum PN hosting policy apply fails

Expand Down
Loading