Remote Term 3.14 to 3.15 #232

New Issue

2026-10-05T02:05:05+02:00

adam commented

2026-10-05 02:05:05 +02:00

Hi Jack,

I'm running remoteterm and noticed my deployment is currently built off the fix/cli-response-scoped-subscription branch (commit 27e546f, "Try out request-scoped subscription for console commands") rather than main, because we needed the CLI interface fix in that branch to work reliably.

Looking at the diff, that commit rewrites fetch_contact_cli_response() in app/routers/server_control.py to fix a race condition: CLI responses (txt_type=1 CONTACT_MSG_RECV events) could be consumed by the permanent handler in event_handlers.on_contact_message before the polling loop in fetch_contact_cli_response saw them, causing spurious timeouts even when the radio had actually responded. The fix adds a request-scoped subscription (via mc.subscribe with attribute_filters) alongside the existing get_msg() polling loop, plus a _flush_pending_messages step to drain stale buffered responses before sending a new command.

I've since checked and this fix is not present on main (currently at 3.15.2) — fetch_contact_cli_response there is still the older bare polling implementation without the scoped subscription or pre-send flush.

Could you let me know:

Is fix/cli-response-scoped-subscription still planned to be merged into main, or was it abandoned/superseded by a different approach?
If it's still planned, is there a rough timeline, or anything blocking it (e.g. more testing, a different fix direction)?
If it was superseded, is the CLI response race condition considered fixed some other way on main that I might be missing?

I'd like to get onto main for the newer releases (3.15.0–3.15.2) without losing this fix, so any guidance on whether to expect it upstream soon vs. whether I should maintain it as a rebased local patch would help.

Thanks for the great project!

Thanks Mike-N3BSQ

Hi Jack, I'm running remoteterm and noticed my deployment is currently built off the `fix/cli-response-scoped-subscription` branch (commit `27e546f`, "Try out request-scoped subscription for console commands") rather than `main`, because we needed the CLI interface fix in that branch to work reliably. Looking at the diff, that commit rewrites `fetch_contact_cli_response()` in `app/routers/server_control.py` to fix a race condition: CLI responses (txt_type=1 CONTACT_MSG_RECV events) could be consumed by the permanent handler in `event_handlers.on_contact_message` before the polling loop in `fetch_contact_cli_response` saw them, causing spurious timeouts even when the radio had actually responded. The fix adds a request-scoped subscription (via `mc.subscribe` with `attribute_filters`) alongside the existing `get_msg()` polling loop, plus a `_flush_pending_messages` step to drain stale buffered responses before sending a new command. I've since checked and this fix is not present on `main` (currently at 3.15.2) — `fetch_contact_cli_response` there is still the older bare polling implementation without the scoped subscription or pre-send flush. Could you let me know: 1. Is `fix/cli-response-scoped-subscription` still planned to be merged into `main`, or was it abandoned/superseded by a different approach? 2. If it's still planned, is there a rough timeline, or anything blocking it (e.g. more testing, a different fix direction)? 3. If it was superseded, is the CLI response race condition considered fixed some other way on `main` that I might be missing? I'd like to get onto `main` for the newer releases (3.15.0–3.15.2) without losing this fix, so any guidance on whether to expect it upstream soon vs. whether I should maintain it as a rebased local patch would help. Thanks for the great project! Thanks Mike-N3BSQ

adam closed this issue

2026-10-05 02:05:05 +02:00

adam commented

2026-10-05 02:05:06 +02:00

I am working today and tomorrow to get things a bit more up to speed; I'll get my head around the state of this situation and what's needed to get it merged, and then cut a release.

I am working today and tomorrow to get things a bit more up to speed; I'll get my head around the state of this situation and what's needed to get it merged, and then cut a release.

adam commented

2026-10-05 02:05:07 +02:00

Okay I'm gonna get this merged in and rebuild in about an hour, so it'll land in the new latest version

Okay I'm gonna get this merged in and rebuild in about an hour, so it'll land in the new latest version

adam commented

2026-10-05 02:05:07 +02:00

All merged; starting my full end to end build stuff so probably up in ~30 minutes to docker unless something goes sideways

All merged; starting my full end to end build stuff so probably up in ~30 minutes to docker unless something goes sideways

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#232