Never ending spurious '[ERR] CMGR: Unknown connid' messages

[dunkfan]

My node 0.18.3 is continuously complaining about unknown connections
Immediately before this [ERR] there is a [INF] SRVR: Removing conn req: message or 2 messages for the clearnet and tor address of the channel.
These repeat at regular intervals (multiple minutes in between)
If I use a lncli disconnect with the pubkey, the connection is immediately restored and the errors disappear for a prolonged period.
Anyone know what is going on here? It seems like this is killing off transactions from going through the corresponding channels but I can't be sure.

[bitromortac]

Could you paste some original (releveant) logs? The string Unknown connid seems to not be part of v0.18.3.

[bitromortac]

Thank you, I have seen those as well. I think it's not a severe issue, but it should be fixed to get rid of ERR spam. I'll investigate this.

[dunkfan]

Thanks sounds good

[bitromortac]

I have found an issue where a similar error happens:

• a peer connects, InboundPeerConnected is called
• we also connect to the same peer, OutboundPeerConnected is called
  • we remove the connection request from ConnManager because we already have a connection with the peer
• the peer disconnects and reconnects, InboundPeerConnected is called
  • we check if we are not already connected, and if so cancel all connection requests, calling cancelConnReqs
  • because a connection request is still found in s.persistentConnReqs from the previous connectToPersistentPeer, we try to remove the connection request from ConnManager, which fails with Unknown connid because it was already removed before

The issue is that s.persistentConnReqs is de-synchronized with ConnManager's internal state, which could also happen in your case. These de-syncs may get fixed in a future refactor of the peer sync mechanics, cc @yyforyongyu.

[dunkfan]

Thanks!
Shutting down my clearnet address which was running via a well known VPN has "solved" the problem
AND My transactions have increased significantly...

[yyforyongyu]

maybe we should create an issue based on the analysis so we don't forget?