Bug 240776 - Nicklist user status desync after server reconnect
Summary: Nicklist user status desync after server reconnect
Status: RESOLVED FIXED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.2.3
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-05 02:25 UTC by Jonas Thiem
Modified: 2010-06-15 21:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
First screenshot as described above (158.56 KB, image/png)
2010-06-05 02:25 UTC, Jonas Thiem
Details
Second screenshot as mentioned above (156.15 KB, image/png)
2010-06-05 02:26 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-06-05 02:25:51 UTC
Created attachment 47685 [details]
First screenshot as described above

Version:           1.2.3 (using KDE 4.4.2) 
OS:                Linux

Sometimes when a server goes down, restarts and konversation reconnects it keeps some of the old channel status icons in the nicklist of user statusses that were in place _before_ the reconnect.

This seems to happen in particular to me when issuing multiple connections to the same server (I tested this with a locally running IRCd on my computer).

The attached screenshots show the bug happening:
- The *first* screenshot is the one of the user connection arriving *secondly*. Everything right here.
- The *second* screenshot is the one that arrived first. You can see the other connection arrive afterwards, and the user of that connection is shown opped until you can spot no MODE event that would op him and also NAMES shows that the user clearly is not opped.

Reproducible: Sometimes

Steps to Reproduce:
1. Start a local IRCd
2. Connect twice, join the same channel in both instances
3. Make sure you are opped for both users/connections to the server
4. Restart the server
5. Wait for the automatic reconnect and subsequent channel rejoin to happen

Actual Results:  
Sometimes one of the two connections will show BOTH users in the rejoined channel still opped, although through the reconnect only the user connection which reconnected faster is actually opped (a /names confirms the desync, also see attached screenshots) [tested in an unregistered channel with automatic opping of the first joining user, while the second one remains unopped]

Expected Results:  
Only the correct user is displayed as an op as reflected by the /names output

The IRCd used for testing was WeIRCd. I believe this issue is unrelated of the particular IRCd though
Comment 1 Jonas Thiem 2010-06-05 02:26:40 UTC
Created attachment 47686 [details]
Second screenshot as mentioned above
Comment 2 Eike Hein 2010-06-15 21:03:03 UTC
Fixed in git master.