There might be non-PUBLISH packets in the send buffer

[smurfix]

Specifically I saw this problem with a Subscribe packet, due to #17, but nothing prevents this case from happening for other reasons.

[coveralls]

Pull Request Test Coverage Report for Build 11742929093

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 82.816%

---

Totals
Change from base Build 11742579634:	0.0%
Covered Lines:	6699
Relevant Lines:	8089

---

💛 - Coveralls

[agronholm]

I'm not sure that any non-publish packets should be resent. I need to understand why there are such packets in the buffer (I thought there wouldn't be, hence the assert).

[smurfix]

Consider what happens when the client tries to (un)subscribe to some topic, but the server dies and disconnects before it can send the reply.

[agronholm]

Consider what happens when the client tries to (un)subscribe to some topic, but the server dies and disconnects before it can send the reply.

The client will then reset the client state machine, which either leaves the outbound buffer empty (with clean session enabled, or only the publish packets in it otherwise). I see, however, that self._pending_packets is not cleared in reset() which could lead to a problem.

[agronholm]

Thus my thinking right now is that my original code in _handle_packet() was correct, but the code in the reset() method is not.

[agronholm]

At any rate, this needs a new test.