Inconsistent state between telnet and HTTP API (MHEARD and LINKS) until restart

[IanHenry]

Description

There appears to be a state consistency issue between LinBPQ’s telnet interface and the HTTP API.

After normal operation, the telnet interface continues to show correct live state for MHEARD and links, while the HTTP API (/api/mheard, /api/links) becomes inconsistent or stale following session disconnect events. A restart of LinBPQ restores consistency.

This suggests a divergence between internal live state tables and the structures used by the HTTP API layer.

---

Steps to reproduce

1. Start LinBPQ with RF port(s) active
2. A remote station initiates an inbound RF connection
   (station connects to the node; node does not initiate the link)
3. Verify state in both interfaces:
   • Telnet MHEARD shows station correctly
   • /api/mheard shows station correctly
   • /api/links reflects correct link state (if active links exist)
4. Remote station disconnects normally
5. Observe:
   • Telnet MHEARD still shows correct expected state
   • /api/mheard no longer matches telnet output (entry missing or stale)
   • /api/links may also show stale or missing link state
6. Restart LinBPQ
7. Both MHEARD and LINKS become consistent again across telnet and API

---

Expected behaviour

Telnet and HTTP API should reflect the same underlying live state for:

• MHEARD entries
• active links

without requiring a restart to resynchronise.

---

Actual behaviour

• Telnet displays correct live MHEARD and link state
• HTTP API (/api/mheard, /api/links) becomes inconsistent after disconnect events
• State corrects only after restarting LinBPQ

---

Notes / observations

• MHEARD persistence exists via MHSave.txt
• API MHEARD implemented via sendPortMHList() → BuildPortMH()
• LINKS API implemented via sendLinks()
• Issue appears after remote inbound session disconnect events
• Suggests divergence between live internal state and API snapshot/rebuild paths

---

Impact

• External dashboards using HTTP API may show incorrect topology or node visibility
• Telnet interface and API do not agree on system state
• Requires restart to resynchronise views

---

[g8bpq]

I tried to reply via email but it bounced. I sent:

I don't see how the code can do that. Are you sure it isn't a case of the browser caching the reply?

73,
john

[IanHenry]

Hi John,Thanks for your reply. I tried just using curl from the command line too (so no browser caching). Mheard on port 1 (rf) via the linbpq api using curl or a browser returned an empty array but via telnet mh 1 showed the callsign that had recently connectedRestarting linbpq restored api functionality and it began reporting the same as Telnet. I’m not sure how the api works under the hood and if it’s doing something different to the Telnet commands. This same behavior has happened multiple times on my setup.I’m writing my own fastapi for monitoring anyway so can get that to use Telnet rather than the linbpq api but thought I’d report the strange behavior anyway in case you could think why or it helps in some way.Thanks for an amazing tool and all your work developing this.73,IanOn 3 Jun 2026, at 18:46, John Wiseman ***@***.***> wrote:g8bpq left a comment (g8bpq/linbpq#9) I tried to reply via email but it bounced. I sent: I don't see how the code can do that. Are you sure it isn't a case of the browser caching the reply? 73, john —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[g8bpq]

BuildPortMH and the MH node command take data fron the same place. Also I can't reproduce the problem here. Does it happen every time you receive a connection?