-
-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong message ID for messages sent from client #529
Comments
Same issue over here ^ - we're working around this in our codebase by playing a game of telephone, which isn't ideal >.< |
If that can be of any interest for anyone, I fixed this issue on this fork: I generate a temporary ID, send it with the message in its "client-nonce" tag, wait for receiving a message ID, check if its client-nonce tag matches one of the sent messages, if so, I emit the new message event with the proper message ID. (needs further testing to make sure it's ok tho) |
This issue is still open, I shall hope it will be done soon I forked the work's @Durss but it didn't resolved the problem |
There's no more /commands available since Twitch disabled them all (except for /me) last fabruary,. Here is a migration guide for every /command |
Hello :)
There's a very tricky issue with v1.8.5 of tmi.js that might still be an issue with v1.9.0 with this line:
tmi.js/lib/ClientBase.js
Line 849 in 4f05e47
(haven't tested with 1.9.0 sorry)
The base of the problem is that when sending a message from TMI.js, we get a
on("message")
event with a sort of fake message built up by TMI.js as twitch does not send us back the message.On every USERSTATE event you keep the tags and stuff on a sort of cache so you can populate the next fake data with tags of the previous message. Including its ID.
The ideal would be that TMI would use the client-nonce and wait for the USERSTATE to call the
on("message")
with proper data on it so the user does not have to worry about this.As this is not managed yet (on neither version if i'm not mistaken), I managed it on my side for now.
But, as you recycle the tags from the previous USERSTATE event, including the message ID, the new message receives the previous message ID. Because of this, if we try to delete a message based on this ID we actually delete the previous message.
A quick and dirty workaround is to delete the ID before storing it on the local cache:
Thanks for you work !
The text was updated successfully, but these errors were encountered: