Hans Klunder

I just checked, I can reproduce the problem e.g.: Running `npm test` while `redis-cli monitor` is active gives things like: ``` 1654887375.958952 [0 172.17.0.1:40986] "get" "will:undefined:12345" 1654887375.961158 [0 172.17.0.1:40986] "del"...

Ok, there were 7 occurences of `undefined` in Redis Monitor generated by `npm test` The first 3: ``` 1654887375.951618 [0 172.17.0.1:40986] "lrem" "will" "0" "will:undefined:12345" 1654887375.958952 [0 172.17.0.1:40986] "get" "will:undefined:12345"...

Small update: I just tried to replicate the issue on `[email protected]` with the following steps: ``` - start redis - start example.js - mqtt subscribe -i subscriber -t hello -q...

Ok, my bad :-( The exact scenario is: ``` - start redis - start example.js - mqtt subscribe -i subscriber -t hello -q 1 - stop example.js - start example.js...

OK, I did some more digging and found the issue :-) The issue is not with the `rpush` but with rebuilding the trie on startup, caused by https://github.com/moscajs/aedes-persistence-redis/pull/96/commits/7d517a70948f1fb44d7dd650c491bd382c10e9b4. Unfortunately in:...

Btw: having some method of type checking would have helped in avoiding the need for all 3 PR's ;-)

One more thing: ``` "lrem" "will" "0" "will:undefined:publisher" "get" "will:undefined:publisher" "del" "will:undefined:publisher" ``` seems to be a bug in Aedes itself, caused by inconsistencies in the interface :-( The sequence...

See also: https://nodejs.org/api/webstreams.html#web-streams-api

FYI: maybe the following can help in the discussion: Opifex uses the concept of a MQTT-conn which is a kind of socket that produces and consumes MQTT packet objects. The...

FYI: to get a hint of where Opifex is going with MQTTv5 see: https://github.com/seriousme/opifex/tree/mqttv5/mqttPacket e.g.: https://github.com/seriousme/opifex/blob/mqttv5/mqttPacket/connect.ts I have about 8 more packets to upgrade and then it should support 3,4...