Closed MattBrittan closed 9 months ago
Looking into this further we need to move away from using golang.org/x/sync/semaphore
to control the number of inflight messages. This is because the spec states:
The send quota is not incremented if it is already equal to the initial send quota. The attempt to increment above the initial send quota might be caused by the re-transmission of a PUBREL packet after a new Network Connection is established.
If this happens with a semaphore
then we get the panic seen in my issue (note: I am not saying this was the cause of that particular panic; just that it's possible). I am am raising a change to implement this (should prevent this crash and hopefully provide insight into the cause).
Closing this because the fix will prevent it recurring and represents a fairly major change (meaning the issue as reported no longer exists).
Describe the bug
Encountered this on a node I'm using for testing; no more debugging info available. Currently don't have enough info to reproduce this.
It appears that the client received an unexpected
Puback
. As the semaphore code needs some work regardless I'm not going to dig deeper right now (will make some changes to how this works and add extra logging at the same time).relevant ClientConfig settings:
To reproduce
Started remote note, panic occurred almost immediately. This note publishes QOS1 messages; I'm guessing that the issue is that it received an unexpected ACK (currently the code releases the semaphore without checking that there is an entry in the session state map).
Upon restart the app ran normally (local session state was empty).
Expected behaviour
Does not panic! (initial change would be to log this)
Software used: