I am using the library to subscribe to a variety of discord events, and somehow some SUBSCRIBE messages weren't acknowledged (resulting in the function waiting for the acknowledgement). Other events were subscribed to successfully, but never fired (as other issues pointed out).
When I looked into the code, I found two issues:
In the decode() function of ipc.js, there was a chance that socket.read() read multiple packets at once. Because the function then proceeds to read the length of only the first packet, any following packets are discarded (and never read).
As a hacky solution, i checked if packet.length was greater than the size of the first packet, and if yes, read the rest aswell.
The second issue is, as pointed out by others, the generation of subkeys.
The problem with having data in the data field instead of args was for example already mentioned here #110 .
I encountered another problem:
Subscriptions to the events VOICE_STATE_CREATE/UPDATE/DELETE are stored with the channel ID. This makes sense, because you could subscribe to multiple channels I guess.
Unfortunately, the dispatch payload does not carry the information about the channel, so there is no way to match the dispatch with the subscription (Documentation).
Again, a hacky solution of me was to just store the event instead of the subkey. This means, incoming events will fire, but there is no distinction between different channels.
Hi,
I am using the library to subscribe to a variety of discord events, and somehow some SUBSCRIBE messages weren't acknowledged (resulting in the function waiting for the acknowledgement). Other events were subscribed to successfully, but never fired (as other issues pointed out). When I looked into the code, I found two issues:
In the
decode()
function ofipc.js
, there was a chance thatsocket.read()
read multiple packets at once. Because the function then proceeds to read the length of only the first packet, any following packets are discarded (and never read). As a hacky solution, i checked ifpacket.length
was greater than the size of the first packet, and if yes, read the rest aswell.The second issue is, as pointed out by others, the generation of subkeys. The problem with having data in the data field instead of args was for example already mentioned here #110 . I encountered another problem: Subscriptions to the events
VOICE_STATE_CREATE/UPDATE/DELETE
are stored with the channel ID. This makes sense, because you could subscribe to multiple channels I guess. Unfortunately, the dispatch payload does not carry the information about the channel, so there is no way to match the dispatch with the subscription (Documentation). Again, a hacky solution of me was to just store the event instead of the subkey. This means, incoming events will fire, but there is no distinction between different channels.Best regards, and thanks for the amazing work!