mirror of
https://github.com/jkingsman/Remote-Terminal-for-MeshCore.git
synced 2026-10-30 22:41:57 +01:00
Persistence between browser instances #62
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/Remote-Terminal-for-MeshCore#62
Reference in new issue
Block a user
I can have Remote Terminal open for days and it accumulates plenty of data in multiple views. However, when I close the browser or reboot, when I reopen it all of the public messages, node map, visualizer, etc. are all unpopulated. Considering there's a local db involved I feel it would be really cool if all that persisted between browser instances.
It's normal for the visualizer/packet feed to flush out; those are just based on packets that arrive to the frontend while they're open and are intended as snapshot/aquarium-style visualizations that don't draw on the backend (plus they get pretty useless unless you're trimming data, which is why the visualizer offers a sliding-time-window system -- if we visualized every node we know, it'd be unusable with thousands of entries).
Public messages (and any other DMs/rooms) should always persist -- those are saved messages; if those aren't showing back up, there's a much larger issue. The node map also is persistent and should use all available historical data.
If, indeed, you are losing the node map and all messages, it sounds like you've got a database persistence issue (beyond the as-designed visualizers and packet feeds). How are you running the app (Docker or checkout)? What do your backend logs look like? Are there any errors about opening the database or writing to it?
Do your statistics show that you're storing channel messages like this:
I would strongly suspect you have some errors in your logs -- try restarting the service and seeing what your logs say about database startup. If you'd like, you can pull the latest version and provide the output from the debug endpoint (Settings -> About -> "Open debug support snapshot"). If you'd prefer not to share your logs (which can provide room names, etc.), you can just copy up to the
STOP COPYING HERE IF YOU DO NOT WANT TO INCLUDE LOGS BELOWblock and everything above is anonymized except for your public key and integration names (not integration details).As far as I can tell my direct uv-based env is not throwing errors. You are correct that the public/channel messages are saved and DM/rooms, node map persist. I suppose it was the packet feed and visualizer I initially saw empty. In my defense, I'm the only meshcore presence in my area, and I use those tools to glance-check topology between my nodes. Waiting on 6 hour flood adverts (in my setup), or manually flood-adverting each repeater anytime the browser restarts was what I was trying to get around.
I could just be using it incorrectly 😆
Thank you for the detailed reply
Ahhh gotcha. Well I'm glad to hear your environment is working! Ultimately, there's no wrong way to use the application, but those features are definitely intended more as novelty visualization systems busy meshes, not so much for node to node debugging. I usually put it on a separate screen and watch my local mesh which has 10-20 packets per minute at least.
When you talk about topology, what specifically do you mean? I wonder if there's a way I can get you the info you're interested without resorting to backend fetchs for the realtime visualizations, but to surface it another way. You can see recent node advert history in the contact info pane (by clicking any contact name; it's much richer for fully advert'd identities) like this:
Would that be helpful? Interested to learn more about what specifically you'd like to accomplish 🙂
Oh, interesting, I don't get that kind of information about other nodes. When I pull up the contact pane, I get:
I'm on Linux Mint 22.3, Chromium 146.0.7680.71, Remote Terminal 3.5.0
I'll try to get more detailed logs tomorrow
How interesting. Under the network tab, can you see what request is failing and what the response is? That implies a bugged API endpoint returning HTML which is weird. You're not doing anything funky with request proxying? Maybe try a frontend cache clear/hard refresh?
It appears the request is successful, but does respond with HTML. I'm not doing any fancy proxying that I know of.
Very interesting. Is it possible you're running a new frontend on an older backend? I'm wondering if this API call is falling through to static fetching.
Did this end up resolving for you? Did you figure out if your backend and frontend were in sync? I've adjusted the behavior to return a clearer error message if you request an API endpoint that doesn't exist in
84c500d018which should help you figure out the nature of the mismatch (I suspect you had a newer frontend that was trying to hit a backend endpoint that did not exist, and thus was serving the main page as a fallback, which was "intended" behavior but dumb, and fixed in that commit.I'm gonna close this for now. If you still have issues after ensuring both frontend and backend are up to date, and the frontend is freshly built, feel free to reopen 🙂