Proposal: guarantee message sent successfully if SendMessage() returns no error

[SoMuchForSubtlety]

Right now errors are handled by the errorHandler, but it's not possible to determine for what message the error was and thus handling it is not really possible.

It is possible to determine if the message was sent successfully if we wait for the ws to respond with either an error or confirmation.
There would need to be a mutex for the ws that gets locked every time we send a message until confirmation is received to prevent getting errors or confirmation meant for a different message.

[xDashh]

As far as I know the backend isn't transactional, i.e. reception of an ERR message can be arbitrarily delayed, or happen only after you sent another message already (although the error relating to the prior message). So you will need a heuristic in any case, e.g. waiting for a second for an error to occur... Not sure how others are handling this right now.

[SoMuchForSubtlety]

Isn't this how chat-gui handles it currently? Or how does it know whether the message was valid?

If a public message was sent successfully we should (almost) immediately get the same message back on the ws feed. Same for private messages and PRIVMSGSENT. This this should cover most cases.

Worst case if the error takes a few seconds to arrive sending messages is blocked for that duration.

[voloshink]

The way the chat server is currently designed, there's nothing that associates the error messages you get back with sent messages, so I don't think it would make sense for an api wrapper to provide that feature.

[xDashh]

chat-gui simply prints the "invalid message" as soon as it receives the ERR and ignorant of which message from the user it actually relates to. (afaik)

[voloshink]

Yeah, none of the dgg clients i've seen or wrote ever handle the errors like that. It's definitely doable but it's a little hacky since it goes against how the server API is written.

[SoMuchForSubtlety]

Would It be feasible to add a handler that gets called every time anything is received on the websocket. So users can hack their own implementation of confirming a message was sent.

[slugalisk]

if clients added a nonce to sent messages it could be echoed in the PRIVMSG and their client could check it off when it's received... something like a random or incrementing int or a unix epoch would work