[omniscient_oce]

I'd say one of the important ones for me is what are the mechanisms for retries under network loss or lack of connectivity in general. What is the behaviour/semantics of that? Can I buffer messages that then get backfilled when a recipient reconnects or do I need to do that in my code / application layer.

[durkes]

It's coded to retry connecting every 500ms. Usually the connection will have to timeout first, so it takes longer for each retry. I set my retries to Infinity.

Messages that the client publishes while trying to connect are pending also every 500ms to try to resend as soon as it connects. This might be something that should be customizable to return an error or retry in a future version.

Because this design is send and forget / fire and forget (similar to redis), messages published when a client is not connected will not make it to that client. If receipt confirmations are needed, it would need to be coded into the app using pubsub.

Thanks for the reply! I will get this info added to the docs soon.

[melony]

Any exponential backoff in the event of unresponsive endpoint? How doea the library deal with increasing backpressure?

[durkes]

There isn't any exponential backoff built-in, just the 500ms timeout in between fails. You can, however, set the number of retries to something you want your app to tolerate and then if it still fails, handle the error accordingly to pager duty or your own custom logic, etc.

Example w/ retries config: https://github.com/durkes/wubsub/blob/main/examples/client.j...

Regarding the backpressure for messages that the client is trying to publish while not connected, they will each be held in a setTimeout recursively until successful trying every 500ms also. If you build in your own custom receipt logic, this could be avoided. I considered building this in but wanted to keep it simple. Open to suggestions.