[BUG] Meshcore define forward path not being set on devices

[Snayler]

Had to open another issue as claude seems to ignore comments made on issues. The problem described in #4625 was not correctly identified as a simple loss of ack on radio chatter. Trying to set a custom path for any contact on my nodes always spits out the error message and no path is ever defined on the devices. Both devices are connected through wifi instead of serial. I believe it's some issue on how meshmonitor is trying to communicate with the devices.

Host OS: Debian Linux
Deployment type: Baremetal v4.14.0
Node type: Heltec V4 and Heltec Wireless Stick V3
Node Connection Type: Wifi

[Yeraze]

Thanks for opening a fresh issue for this, and sorry the first one got closed before your follow-up comment was addressed — checked for duplicates and there's no other open issue covering this, so treating it as a continuation of #4625.

Classification: Bug Report.

Why this needs more info before I can pin down the fix

The theory behind the #4625 fix (merged in commit e5c9efe8, PR #4628) was: set_out_path (firmware CMD_ADD_UPDATE_CONTACT, opcode 9) applies the write correctly, but the device's Ok acknowledgement is frequently lost in radio chatter, and meshcore.js was treating that lost ack as an outright failure. The fix makes MeshMonitor treat an ack-timeout as success (optimistic mirroring) instead of a 409 error.

You flagged on #4625 that this doesn't match what you're seeing — the path is genuinely absent on the device afterward, not just under-acknowledged. That's a materially different failure mode than what the merged fix addresses: if it were really just a lost ack, meshcore.js would eventually return successfully (or time out) while the write had already landed — it wouldn't be a hard rejection every time. A 100%-reproducible error with nothing written suggests either:

• You're still on a MeshMonitor build that predates the [BUG] Meshcore define forwarding path error #4625/fix(meshcore): treat a lost out_path ack as success, not failure (#4625) #4628 fix (v4.14.0, as you listed, is before it — the fix shipped in 4.14.1-rc2), so you're seeing the old spurious-409-on-timeout behavior and we genuinely don't know yet whether the write is landing or not, or
• You're on a build that includes the fix and it's still hard-failing (applied: false), which only happens when the device/meshcore.js returns an explicit non-timeout rejection — a different bug than [BUG] Meshcore define forwarding path error #4625 entirely, closer to the underlying WiFi-companion communication itself than to ack timing.

To tell those apart, could you provide:

1. Exact MeshMonitor version currently running (Settings → About, or the footer) — specifically whether it's ≥ 4.14.1-rc2.
2. The exact error text shown in the UI on the latest attempt.
3. Server-side log lines around the failure — look for [MeshCore] set_out_path rejected for <publicKey>: <error> or [MeshCore] set_out_path ack not seen for... in the MeshMonitor container/service logs at the time you click Save. That message contains the actual meshcore.js/firmware error text and will tell us definitively whether this is a timeout or a hard rejection.
4. Companion firmware version on the Heltec V4 / Wireless Stick V3 (visible in the official MeshCore app's device info, or via ver over the CLI).
5. Whether this ever works — any contact, any path length — or fails 100% of the time on both devices.
6. Confirmation (via the official MeshCore app, since you mentioned you've set paths there successfully before) that immediately after a MeshMonitor "failure," the path is still empty on the device — just to be certain we're not looking at a UI-refresh/caching issue on MeshMonitor's side instead.

Once we know whether this is a timeout being mis-reported as a fresh failure (in which case there's a separate, still-open PR #4626 that adds actual device-side verification by re-reading get_contacts after a timeout, which would be the right fix to land) versus a genuine rejection over the WiFi companion transport (which would need different investigation into the TCP companion link itself), I can move forward with a concrete fix.

-- Authored by Roger 🤓

---

Generated by Claude Code

[Yeraze]

Deep-dived the code path for this. I can't run it against your Heltec devices, so treat everything below as a diagnosis to test, not a confirmed root cause — but the WiFi angle you flagged is very likely real, and it points somewhere specific.

What the write actually does

Setting a forward path calls CMD_ADD_UPDATE_CONTACT (opcode 9) in meshcore.js — setContactPath → addOrUpdateContact → a single frame on the wire. Two things about that frame matter here:

1. It is by far the largest companion command. Its payload is fixed at ~143 bytes (32-byte pubkey + a full 64-byte out_path buffer + a 32-byte name + coords). Almost every other companion command is under ~10 bytes. So this is the one command whose frame is big enough to stress a transport.

2. Its success/failure is an uncorrelated ack. addOrUpdateContact does this.once('Ok') / this.once('Err') on a global emitter — meshcore.js fires those for every device reply frame, with nothing tying a reply back to the command that caused it. And unlike our radio ops (e.g. discover_path), set_out_path is not serialized against the rest of the connection, so the Analyzer/poller traffic runs concurrently with its ack wait.

Two candidate root causes, ranked

(1) Large-frame fragmentation over the WiFi/TCP companion link (most likely).
Over serial the frame arrives as one contiguous write. Over WiFi it's a TCP stream that can fragment mid-frame. If the firmware's WiFi companion reader reassembles a ~147-byte frame less robustly than its serial reader, it rejects or drops it and returns Err — deterministically, every time, for this one oversized command, while every small command keeps working. That matches your report exactly: only path-setting fails, it fails on any contact, and the path is never applied. This is firmware-side and nothing MeshMonitor can force, but see below.

(2) Uncorrelated Ok/Err ack race.
A reply meant for a concurrent poller command satisfies set_out_path's once('Err') and rejects it. This explains the error message, but it can't fully explain "the path is never set" — the write frame still went out, so the device would usually apply it anyway. So I think this is secondary to (1), though it may compound it.

Note #4625 only addressed the opposite direction (a lost Ok → false timeout). A genuine Err — which is what both hypotheses produce — is not, and can't be, papered over at that layer, so #4625 doesn't change your symptom.

What would confirm it, and the fix I'd propose

The honest fix, and the one that also diagnoses this, is a read-back verification: after the write, re-fetch the contact from the device and compare its stored out_path to what we sent, and report that rather than trusting the ack. Over any transport this turns "the device rejected the request" (a guess) into a truthful "the device did not persist the path" or a real success — and it would immediately tell us whether hypothesis (1) is right, because the read-back would come back empty.

Before I build that, two things that would let me confirm the diagnosis directly:

• Server logs from one failed set at debug level — specifically whether you see a set_out_path rejected: <error> (a real Err) vs an ack timeout.
• Whether serial works where WiFi fails on the same contact. If serial sets the path and WiFi never does, that nails hypothesis (1).

If you can grab either, I'll turn the read-back verification into a PR.