I would like to include handling for timeout situations when using .push_async and would appreciate some guidance on how best to accomplish this.
To provide some context, we first discovered timeout-related issues in our own project upon using Apnotic's connection.join. The join was never returning and there were also notifications that had been queued via .push_async that had not run their on(:response) yet. Our knee jerk solution is to wrap .join in a timeout block and run .close shortly after, whether a timeout occurs or not.
This got me to thinking... if two notifications are sent with the async method, are they always delivered in sequence? If there is some sort of delay with sending the first one, does the second one stay stuck? My guess is that it depends upon how the http2 streams multiplex the notifications. Is this accurate?
Ultimately, I'm hoping to find a robust way to time out these problems and retry but would greatly benefit from some insights on the best way to approach it with this library.
I would like to include handling for timeout situations when using
.push_asyncand would appreciate some guidance on how best to accomplish this.To provide some context, we first discovered timeout-related issues in our own project upon using Apnotic's
connection.join. The join was never returning and there were also notifications that had been queued via.push_asyncthat had not run theiron(:response)yet. Our knee jerk solution is to wrap.joinin a timeout block and run.closeshortly after, whether a timeout occurs or not.This got me to thinking... if two notifications are sent with the async method, are they always delivered in sequence? If there is some sort of delay with sending the first one, does the second one stay
stuck? My guess is that it depends upon how the http2 streams multiplex the notifications. Is this accurate?Ultimately, I'm hoping to find a robust way to time out these problems and retry but would greatly benefit from some insights on the best way to approach it with this library.