Bug 249675 - Commands from old connection bleeding into new one after reconnect
Summary: Commands from old connection bleeding into new one after reconnect
Status: RESOLVED WORKSFORME
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.3.1
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: argonel
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2010-08-31 23:25 UTC by Jonas Thiem
Modified: 2018-10-27 02:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The output of a /raw window (6.93 KB, text/plain)
2010-08-31 23:25 UTC, Jonas Thiem
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Thiem 2010-08-31 23:25:12 UTC
Created attachment 51154 [details]
The output of a /raw window

Version:           1.3.1 (using KDE 4.4.5) 
OS:                Linux

After filling up Konvi's send queue with looots of commands to the point where the server will kick me for Excess Flood, Konversation will, after the subsequent reconnect, bleed commands from the old connection into the new one.

To see what sort of commands I'm talking of, see the attached raw output. Apparently, some WHO commands and other stuff gets then sent during the authentication period, and it was probably supposed to get sent before the disconnect happened (and is now, due to a bug, still queued and sent out despite the old connection being gone).

Reproducible: Sometimes

Steps to Reproduce:
1. Apparently a DCC transfer seems to accelerate it for me. Maybe slowing down the connection helps
2. Sent a lot of stuff, but not just PRIVMSGs, but also lots of WHOIS commands
3. Do it so excessively that the server will kick you (if you have trouble at this point, I recommend trying on irc.eloxoph.com which has a relatively harsh flood limit)

Actual Results:  
Reconnect often fails or yields a lot of "Not registered" errors

Expected Results:  
Reconnect works fine and no commands that shouldn't be there are seen in the raw log during authentication
Comment 1 argonel 2010-09-08 08:57:17 UTC
commit e4d7d56a44bb7be7eaa206e297ff7f39b94266ac
Author: eli mackenzie <argonel@gmail.com>
Date:   Wed Sep 8 02:53:45 2010 -0400

    stop the auto-who timer when the server is not connected
    CCBUG:249675

diff --git a/src/irc/channel.cpp b/src/irc/channel.cpp
index 85b8c9d..3a53e9c 100644
--- a/src/irc/channel.cpp
+++ b/src/irc/channel.cpp
@@ -2689,6 +2689,7 @@ void Channel::setActive(bool active)
         topicLine->clear();
         clearModeList();
         clearBanList();
+        m_whoTimer.stop();
     }
 }
Comment 2 argonel 2010-09-08 09:14:24 UTC
commit 0a19c2109f7c8b514240d3f29fa8e2ab43a7355e
Author: eli mackenzie <argonel@gmail.com>
Date:   Wed Sep 8 03:15:21 2010 -0400

    stop the lag timer when disconnected
    CCBUG:249675

diff --git a/src/irc/server.cpp b/src/irc/server.cpp
index 315f54b..f0a6263 100644
--- a/src/irc/server.cpp
+++ b/src/irc/server.cpp
@@ -651,6 +651,7 @@ void Server::broken(KTcpSocket::Error error)
     resetQueues();
 
     m_notifyTimer.stop();
+    m_pingSendTimer.stop();
     m_pingResponseTimer.stop();
     m_inputFilter.setLagMeasuring(false);
     m_currentLag = -1;
Comment 3 Eike Hein 2013-04-15 01:58:32 UTC
Is this still an issue with current versions of Konversation?
Comment 4 Andrew Crouthamel 2018-09-24 02:12:14 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Andrew Crouthamel 2018-10-27 02:15:31 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!