-
Notifications
You must be signed in to change notification settings - Fork 88
Telegram -> IRC message relaying stops #41
Comments
Very odd, I've been running mine for months now without problems. Which IRC network is this on, and can you confirm that you are running the latest version of teleirc (along with up to date libraries in node_modules)? |
Network is Freenode. Teleirc is the latest and for the last 3 days it has been running without problems. Libraries should also be up to date as it is pretty fresh install. It might (but without any evidence) be related to either attachments or possibly reconnecting on IRC network. |
Hey, I haven't been able to reproduce this problem unfortunately. Sorry about the delay also, I'm on a very busy schedule at the moment. I'd very much like to fix this, so if you have logs can you check if:
I'll have to do some more thorough tests with e.g. disconnecting my network connection and checking if teleirc continues working. |
To reproduce this problem seems a bit tricky. As there seems not to be any obvious reasons. Now when there is another channel added we found out that the relaying can stop on one channel but continue on the other. There is no sign in the logs of the messages that are not relayed. So no log stating "relaying to IRC". And the error on IRC side. It is still on both channels and relaying in one direction on both channels. This is what there is then on restart of teleirc. It relays the missing messages. Some lines are here multiple times but not shown on IRC. (id's of channels I obfuscated a bit)
|
I can try (or running at the moment) but as the problem is pretty random it might be difficult to figure out if the problem persists or if it is fixed. Interesting thing to note is that when the bot is on two channels the relaying stopped on one but it continued on other a week ago. |
That's odd for sure. Let's hope that the latest node-irc module fixes the problem, report back if you notice that it doesn't. |
During the night teleirc had some weird functionality. As there are other connections from the specific host to freenode without problems and teleirc had connections to different servers randomly I don't think the problem is with freenode as such. Disconnecting from IRC every 4-5 minutes
(different timezone on server) |
Ouch, something is seriously wrong there... |
I had to revert back to before "node-irc" version because of the connection flooding. Jumping on and off IRC network without reason and flooding IRC. And when connecting also stating the topic every time on telegram thus flooding Telegram. |
sigh time to write our own irc module? :p |
I just ran into this issue. resetting it wasn't doing anything. |
That option should be unrelated to this problem @GeneralUnRest. I believe the problem lies in the IRC module. We're setting up the event listeners once (here), so I'm not sure how they can start firing multiple times unless that module is broken. It is of course a possibility that the TG module is causing problems, but the problem @lagleki described supports the theory of the IRC module being broken since it connected to the IRC network multiple times (taking up several nicks). I have one theory of what happened on your end @kengu2: maybe the connection between your server and the IRC network was down for an extended amount of time, causing lots of ping timeouts and reconnects in the IRC module. I'm trying to study how the module reacts to this situation, and to me it would seem that they never explicitly close a socket that was determined to have timed out? (here). They do manually trigger the 'close' event on the socket, but this AFAIK accomplishes nothing on node's side and they should also call .destroy() on the socket. It may be possible that the socket lingers around after their ping timeouts thus causing the problem. This could explain why a message is relayed to IRC multiple times, but not really the other way around since it seems they really do remove the on 'data' event handler in either case. That is a little bit mysterious. Anyway, I wonder if it would help to add a |
Edit: don't waste your time on this. I've confirmed this issue still persists with that hack. Seems node-irc master branch suffers from this reconnect problem, it's not our fault. I'll open an issue with them, don't use the You can follow the discussion here: martynsmith/node-irc#449 |
@FruitieX Just wanted to let you know that I've pushed a patch that seems to fix this @ martynsmith/node-irc#452. It'd be great if you could give it a try as well so I can get it merged and finally publish the ping timeout support. You were on the right track with Sorry for the trouble. Hope to get this fixed quickly. |
I'm not sure if I should open a new issue for this or not, but I'm having a related but opposite problem. IRC messages for a specific channel aren't getting relayed to Telegram. In fact, there is nothing in the console output to show that the bot attempted to post to Telegram—it's like he bot has write access to the one channel but can't read from it. However, this only is happening for one of the two links I made. On the other channel, it's working normally. It does not depend on which order I list the links in config.js, either. I'll play around with debug mode for a bit and let you know if I find anything else interesting. |
It turns out that the IRC channel name is case-sensitive for reading, but the server I connected to is not case-sensitive, so it will forward messages to #CHANNEL to #channel. |
This sounds like #36. |
It seems to be exactly #36. |
@FruitieX Just letting you know that I've published node-irc 0.5.0 that has the fix for this in it. |
Thank you very much for the note @jirwin, I will work towards a new hotfix release for next week when I'm finished with holidays. :) |
Right, so this should be fixed now in the branch |
After running teleirc for some days there have now been two occasions where the messages from Telegram are not passed on to IRC but works all the time the other way round. There is no sign of those messages in the debug.
After restart the missing messages are relayed from the queue.
The text was updated successfully, but these errors were encountered: