jdev - 2021-06-04

oooh, fuzz testing my message styling parser and I found an interesting one. The string "````" makes a good test. I believe it should be the start of a pre-formatted block with "`" as the info string, but my parser somehow spits out that it's the end of a preformatted block with the info string "`" but also a separate plain token "`". None of which makes any sense and I have no idea how it's even possible :)

oh no, not a start one because it has no \n. Still, it shouldn't be an end one without a corresponding start one.

Fuzz all the things!

parser hard

Sam: are you documenting all those cases somewhere in machine-readable format?

maybe a bot that would send all those messages to a requesting client?

maybe some kind of grammar?

Ge0rG: I'm not updating it regularly, but yes, I've got all my tests as a JSON blob other libraries can use if they want

Zash, no, it’s so super simple and edge-case free it doesn’t need a grammar!!!k

I'll add these and stick it up somewhere again after I've gone through all the interesting cases the most recent fuzz stuff found. No crashes, thankfully!

This is a bug in the parser; a grammar probably wouldn't have helped here.

But if you want to write a grammar, be my guest, it would be nice to have.

no, a grammar for such a language is needed, but a PITA to write

Right, that's why I'm not doing it :)

Oh nice, looks like that's the only issue it found, I'm not sure why it marked the rest as interesting. Time to bug fix!

Oh no, re-read the spec, I was right the first time. No \n required.

If I want to check whether there are errors reported (e.g. sending to a non-existing JID) for messages sent by go-sendxmpp. Would be be checking for error replies while sending until one second after sending the last message sufficient? I'd like to find a good compromise between not missing error replies due to closing too early and having a loooong timeout which makes go-sendxmpp look like it's hung. :D

> hung Martin, you could do that in async fashion if you have a way to match the error replies to the messages you sent.

It is already a goroutine. Right now I don't match them to a message as I don't know about the message IDs as I don't generate them myself but let the library do it.

My question is more how long shall I wait for error replies after the last message is sent.

Well, as a person with unstable internet connection, I can say it's higly variable.

I would probably just not wait. Plain XMPP <message/> semantics is fire and forget.

If the users wants some kind of acknowledgement, add optional code for that.

E.g. stream management, so you can check whether the first hop was successful. For later hops, it depends; for MUC messages you could wait for reflections; for 1:1 messages, you could wait for XEP-0184 delivery receipts.

But having a timeout to wait for an error sounds wrong to me.

I also thought sendxmpp tools are just fire and forget, but some people already complained it didn't work and it turned out they had a typo in the receivers JID. :D

I really don't want to implement smacks or such. So I thought just checking whether there are error replies would be an easy to implement "good enough" solution. :D

I would at least make such a behavior optional though. I could imagine other users being annoyed of unnecessary delays (when using this in the context of larger scripts) ...

Seems reasonable.

And you do open the 'it works sometimes' can.

Yeah, go for acks before timeouts

The latter is true when waiting for ACKs as well, but 'timed out waiting for an ACK' is more intuitive feedback than 'timed out waiting for an error, so maybe we're fine'.

If you get an error before the ack, handle that

I use sendxmpp as a sendmail replacement, and that was 100% fire-and-forget

Martin, stream management + waiting for the message to be acked would be good enough. you might not even get errors on jid typos, domain typos may cause errors only minutes after

Ok, then I'll have to look how much effort the smacks stuff will be. :)

Thank you all for your input.