Long IRC messages (a few lines) get broken up and posted out of order

[Kadigan]

bitlbee version 3.5.1, bitlbee-discord pulled from git and built under 2w ago

When I send a long message, it gets broken up into smaller ones even though Discord doesn't need it (it fully supports long messages), and then the chunks are sent out of order sometimes.

[sm00th]

bitlbee-discord doesn't break up messages, so it seems that it is either the irc client or bitlbee who does that. do you happen to know the limit after which the message gets broken up?

[digitalcircuit]

I have had split messages get sent out of order, too, when disabling rate-limiting in my client (Quassel) despite the IRC client sending in the correct order. Might be worthwhile opening a separate bug report for that.

Discord itself has a limit of roughly 2000 characters, it'll mention it if you try pasting very long messages on the web client.

[sm00th]

According to RFC maximum message length is 510 characters (+CR-LF), bitlbee doesn't seem to split messages, just throws an error if max length is exceeded and it gives you twice as much. So it looks like the culprit here is the client and there isn't much we can do here without breaking standards.

As for messages out of order that indeed shouldn't happen but I am not sure how to reproduce this.

[digitalcircuit]

@sm00th I'll try making a reproducible case for the messages out of order problem (maybe sending multiple 10,000 char messages, auto-split by client?) and file a separate issue for that when I have the time.

In the meantime, I've worked around it by temporarily enabling rate limiting in the client, sending a bunch of long messages, then re-disabling rate limiting after they're sent.

[dequis]

It's one http request per sent message, so it makes sense that race conditions are introduced, given enough latency/jitter.

I've done some tests with this in the official client

python -c '[print(str(x) + "\r\n") for x in range(20)]' | xdotool type --delay 1 --file -;

It just sends them one at a time, and you can watch them go from gray (unsent) to white, as the http requests appear in the inspector. Each request takes 200-250ms here (mostly my own latency to the server, i bet) and it seems to send 4-5 requests per second which matches that.

[Kadigan]

@digitalcircuit - I've had the issue on Quassel as well. I assumed it was Bitlbee because Quassel displayed them in the correct order, but Discord did not (so it must've been lost somewhere 'in translation', so to speak).

[sm00th]

Looks like I'll have to implement a message queue and wait for each send to finish before starting the next.

[tecknojock]

On this same topic, splitting across messages greater than 2k characters would be nice as well, since theoretically with paste buffer one in bitlbee you can have issues there.