jdev - 2021-06-04

  1. Sam

    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 :)

  2. Sam

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

  3. Zash

    Fuzz all the things!

  4. jonas’

    parser hard

  5. Ge0rG

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

  6. Ge0rG

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

  7. Zash

    maybe some kind of grammar?

  8. Sam

    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

  9. jonas’

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

  10. Sam

    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!

  11. Sam

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

  12. Sam

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

  13. jonas’

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

  14. Sam

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

  15. Sam

    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!

  16. Sam

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

  17. Martin

    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

  18. selurvedu

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

  19. Martin

    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.

  20. Martin

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

  21. selurvedu

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

  22. Holger

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

  23. Holger

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

  24. Holger

    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.

  25. Holger

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

  26. Martin

    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

  27. Martin

    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

  28. Holger

    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) ...

  29. Martin

    Seems reasonable.

  30. Holger

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

  31. MattJ

    Yeah, go for acks before timeouts

  32. Holger

    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'.

  33. MattJ

    If you get an error before the ack, handle that

  34. moparisthebest

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

  35. jonas’

    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

  36. Martin

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

  37. Martin

    Thank you all for your input.