pubsub.get_message timeout vs disconnection
Both cases (timeout and disconnection) make pubsub.get_message return None, making it difficult to discriminate between them. For instance, I have the following code:
while True:
start = time()
msg = await pubsub.get_message(True, timeout=PING_PERIOD)
if not msg and time() - start < PING_PERIOD: # i.e., disconnected
break
if not msg:
send_ping()
Instead, we could use a sentinel to indicate a timeout happened:
tos = object()
while msg := await pubsub.get_message(True, timeout=PING_PERIOD, timeout_sentinel=tos):
if msg is tos:
send_ping()
Having the default value of timeout_sentinel to be None would maintain backwards compatibility.
@NoneGG what do you think? If you like the idea, I can implement it and send you a PR.
Cheers, and thank you for your work.
@dmbasso Maybe we can just raise the timeout/disconnected error when it happens? (we can offer an option to descide whether the error can be raised when client is initialized)
Yes, that would work too. Please tell me if you need any help implementing this feature.
@dmbasso I read related code again and found both ConnectionError and TimeoutError get proceeded in pubsub._execute, is it necessary for uplayer to know these things?
By "uplayer" do you mean the function that calls pubsub.get_message? In my case, I just need to know that a timeout happened, and I consider CancelledError and ConnectionError as the end of a session (so no need to distinguish between those). Probably the best would be to raise all of them, and let the uplayer deal with it. Especially the CancelledError, since it means the coroutine should end, but the signal gets discarded in line 118.
@dmbasso Maybe we can offer an option for user to descide if these error should be raised?
@NoneGG Sounds good to me.