Channel messages mixed after adding/editing channel, channel not showing up

[sandroshu]

Hi,

I have 2 MT nodes added to MeshMonitor via BLE-Bridge (ghcr.io/yeraze/meshtastic-ble-bridge).
One of them is a Client Base, other is a Client Mute, different name and ID.

Everything works correctly, except client reconnection after leaving from home then coming back, but BLE Bridge container restart always solves this. It would be cool if it auto reconnects but that's not the problem now.

On the Base I have added a new channel (6th) to one of my Meshtastic nodes using MeshMonitor.
After adding the channel the messages from Channel 3 disappeared and reappeared in Channel 0.

Now Channel 3 receives the new messages intended to be there, so it works correctly but the old messages are still in Channel 0 and not in Channel 3.
I somehow triggered this before but if I remember it correctly the problem recovered after container restart. Now it does not recover, old messages from Channel 3 are permanently in Channel 0.

Any way to solve this or am I doing something wrong?

Second problem is Channels can be added via Admin commands and Device config page. I tried Device config page first (reloaded config, edited channel, then reloaded). It did not modify the channel according to the MeshMonitor even after config reload. Then I tried Admin commands. Again, it did not modify the channel. I have reloaded the config then restarted MeshMonitor but changes did not show up.
I then disconnected from the node, then connected via Phone app. The channel was there, so it created/edited the channel, but changes did not show up in MeshMonitor even after reload.
I restarted everything now all the channels including the new one show up in MeshMonitor.

[Yeraze]

Thanks for the detailed write-up. You weren't doing anything wrong: both are bugs, and #5269 fixes them.

1. Channel 3's messages moving into Channel 0

When you add or edit a channel, MeshMonitor checks whether any channel moved to a different slot, so it can carry that channel's messages along. That check matched channels by encryption key alone.

Your Channel 0 and Channel 3 most likely share a key (the default key is common). So adding the new channel made Channel 3 look like it had "moved" to Channel 0, and its whole history was rewritten there. New messages still arrive in the right place, which is why only the old ones are affected.

The fix matches on key and name, which is what a newer copy of that check already did. While there I also fixed two related gaps: that migration could touch your other node's messages, and it could turn a user's per-node channel permission into one covering every node.

About the messages already moved: I'm sorry, but they can't be put back automatically. A stored message doesn't record which key or channel name it came from, so there's no reliable way to tell the moved Channel 3 messages apart from real Channel 0 messages. The fix stops it from happening again.

2. Edits not showing until a restart

Your radio doesn't tell MeshMonitor when a channel changes. After an edit through Admin Commands, MeshMonitor re-read the channel from its own database, which nothing had updated, so the old channel stayed until the next full resync. The fix saves the edited channel as soon as the radio accepts it.

On the Device Configuration page, that editor already saves to MeshMonitor's database, so this fix doesn't explain that page not updating for you. If it still happens after the fix ships, could you tell us exactly which steps you took on that page, and whether any error appeared?

The fix will be in the next release candidate.