Feature Request: Fetching RPT info should be a background process and serialized #236

Open
opened 2026-10-05 02:05:24 +02:00 by adam · 1 comment
Owner

📝 Problem Description

  1. When in the RPT area with Guest/Admin access, everytime the user request some data if the user change the window focus going to a public channel or other contact and then gets back to the RPT window where it asked for the data, the spinning fetch green wheel appears again and it seems that it broke the request.
  2. When in the RPT area with Guest/Admin access, everytime the user request some data all the other data request became greyd out (normal if the code does not handle serialized/queued requests. like in the "Load All" I think).

🚦 Current Behavior

  1. the request is stopped when the focus shift.
  2. all the data requests are greyed out, while the last one finishes

🎯 Expected Behavior

  1. The request should be a background job that populates the RPT request data window while the user navigates to other areas.
  2. The request should be serialized / queued (and add some smal time gap to free some AirTime from the RPT), so the user can queue the needed data requests from the RPT while he does other things.

📋 Steps to Reproduce

  1. click any RPT data request and change focus to another contact or channel or any other area not on that RPT contact.

📡 Radio Node

  • Firmware version: Meshcore-Dev 06-Jun-2026/v1.16.0-07a3ca9
  • Hardware / board type: Xiao S3 WIO

🔌 Connection to the Radio

  • Connected directly to the radio, or through an intermediary? Directly
  • Transport: Serial (USB)

💻 Environment Information

  • OS: Windows 11 x64
  • Browser / Version: MS Edge Version 150.0.4078.48 (Official build) (64-bit)
  • RemoteTerm Version: v3.16.2·f8f6842 "wrapped" HA add-on/app

📸 Screenshots / Debug Logs

Image
## 📝 Problem Description 1. When in the RPT area with Guest/Admin access, everytime the user request some data if the user change the window focus going to a public channel or other contact and then gets back to the RPT window where it asked for the data, the spinning fetch green wheel appears again and it seems that it broke the request. 2. When in the RPT area with Guest/Admin access, everytime the user request some data all the other data request became greyd out (normal if the code does not handle serialized/queued requests. like in the "Load All" I think). ## 🚦 Current Behavior 1. the request is stopped when the focus shift. 2. all the data requests are greyed out, while the last one finishes ## 🎯 Expected Behavior 1. The request should be a background job that populates the RPT request data window while the user navigates to other areas. 2. The request should be serialized / queued (and add some smal time gap to free some AirTime from the RPT), so the user can queue the needed data requests from the RPT while he does other things. ## 📋 Steps to Reproduce 1. click any RPT data request and change focus to another contact or channel or any other area not on that RPT contact. ## 📡 Radio Node - **Firmware version:** Meshcore-Dev 06-Jun-2026/v1.16.0-07a3ca9 - **Hardware / board type:** Xiao S3 WIO ## 🔌 Connection to the Radio - **Connected directly to the radio, or through an intermediary?** Directly - **Transport:** Serial (USB) ## 💻 Environment Information - **OS:** Windows 11 x64 - **Browser / Version:** MS Edge Version 150.0.4078.48 (Official build) (64-bit) - **RemoteTerm Version:** v3.16.2·f8f6842 "wrapped" HA add-on/app ## 📸 Screenshots / Debug Logs <img width="1247" height="209" alt="Image" src="https://github.com/user-attachments/assets/a958db43-509f-4f62-a5a0-3b8daa192abb" /> <!-- github-sync-id:4861146936 -->
Author
Owner

Yeah, this is an unfortunate architecture limitation. Navigating away just serializes the page data for later restore. I don't think this is something I'm going to action in the immediate term, but it's a legitimate limitation and I get the pain, so I'm going to keep this open as a feature for future implementation.

Yeah, this is an unfortunate architecture limitation. Navigating away just serializes the page data for later restore. I don't think this is something I'm going to action in the immediate term, but it's a legitimate limitation and I get the pain, so I'm going to keep this open as a feature for future implementation. <!-- github-comment-id:5037039726 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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