#1786 sasl2 gen generate duplicate messages with Converastions on reconnect
Reporter
Menel
Owner
Nobody
Created
Updated
Stars
★★ (2)
Tags
Priority-Medium
Type-Defect
Status-Invalid
Menel
on
What steps will reproduce the problem?
1: Install conversations lastest version on Android.
2.enable "sasl2"; "sasl2_bind2"; "sasl2_sm";
3. With conversations: Write a message to a room or 1:1
4: Enable flight mode, don't disconnect the account in the options before.
5: wait some minutes (I assume for longer then tcp read timeout)
6: reconnect
What is the expected output?
silent reconnect
What do you see instead?
the client resends some messages, but its not always visible in the sending clients UI.
What version of the product are you using? On what operating system?
1. Using Prosody trunk nightly build 1723 (2022-12-22, 74ed772ff5fb)
lua 5.2 debian bullseye
Please provide any additional information below.
The relevant log:
https://share.snikket.de/J-JQEQ2A07X9ppsbmqfJ7h4l/L0Du5TNYSL-Bh2gQHCrO1A.txt
the resending happens at 22:50:22
Menel
on
Addition:
Initially I did send "!help" to the magicbot@magicbroccoli.de at 22:10 and "!version sasl2.snikket.de" at 22:11. Then I went offline as described above within the next minute.
I went online again at 22:50 (where the log starts) and the client showed me the answer of the bot, without showing me the repeated messages in the UI that I obviously send.
Menel
on
Further testing showed, the issue is the same with only enabling mod_sasl2, the other two are not nessesary for the issue.
Daniel Gultsch
on
Interestingly the client doesn’t attempt to resume (The server log only starts at step 6 I assume?)
Client logs for the initial connect (before step 3 and step 3) and the reconnect (step 6); I think stream management doesn’t get enabled properly on the client side.
It seems it was a Conversations bug and will be fixed by the Conversations release 2.11.3, thanks to iNPUTmice looking into this bug report.
I can't reproduce it with the patched Conversations anymore.
Menel
on
New issue: a reporter should be able to close an issue, so you don't have to do it 😄
What steps will reproduce the problem? 1: Install conversations lastest version on Android. 2.enable "sasl2"; "sasl2_bind2"; "sasl2_sm"; 3. With conversations: Write a message to a room or 1:1 4: Enable flight mode, don't disconnect the account in the options before. 5: wait some minutes (I assume for longer then tcp read timeout) 6: reconnect What is the expected output? silent reconnect What do you see instead? the client resends some messages, but its not always visible in the sending clients UI. What version of the product are you using? On what operating system? 1. Using Prosody trunk nightly build 1723 (2022-12-22, 74ed772ff5fb) lua 5.2 debian bullseye Please provide any additional information below. The relevant log: https://share.snikket.de/J-JQEQ2A07X9ppsbmqfJ7h4l/L0Du5TNYSL-Bh2gQHCrO1A.txt the resending happens at 22:50:22
Addition: Initially I did send "!help" to the magicbot@magicbroccoli.de at 22:10 and "!version sasl2.snikket.de" at 22:11. Then I went offline as described above within the next minute. I went online again at 22:50 (where the log starts) and the client showed me the answer of the bot, without showing me the repeated messages in the UI that I obviously send.
Further testing showed, the issue is the same with only enabling mod_sasl2, the other two are not nessesary for the issue.
Interestingly the client doesn’t attempt to resume (The server log only starts at step 6 I assume?) Client logs for the initial connect (before step 3 and step 3) and the reconnect (step 6); I think stream management doesn’t get enabled properly on the client side.
I can try to get logs for the client too, but that'll take me a bit. Here is another attempt with Prosody trunk nightly build 1725 (2022-12-29, 944c7f0f1a9e) https://paste.debian.net/hidden/827264bd/ Or https://share.snikket.de/gqHynLWQNC5koqNyAuDXUWwW/_WLUT5LsTrCtHrfDsDyUZQ.txt
It seems it was a Conversations bug and will be fixed by the Conversations release 2.11.3, thanks to iNPUTmice looking into this bug report. I can't reproduce it with the patched Conversations anymore.
New issue: a reporter should be able to close an issue, so you don't have to do it 😄
Thanks all.
Changes