Don't set `Context._error` to expected `ContextCancelled`
If the one side of an inter-actor context cancels the other then that side should always expect back a `ContextCancelled` message. However we should not set this error in this case (where the cancel request was sent and a `ContextCancelled` msg was received back) since it may override some other error that caused the cancellation request to be sent out in the first place. As an example when a context opens another context to a peer and some error happens which causes the second peer context to be cancelled but we want to propagate the original error. Fixes the issue found in https://github.com/pikers/piker/issues/244expected_ctx_cancelled
parent
9650b010de
commit
e2139c2bf0
|
@ -425,7 +425,17 @@ class Context:
|
|||
f'Remote context error for {self.chan.uid}:{self.cid}:\n'
|
||||
f'{msg["error"]["tb_str"]}'
|
||||
)
|
||||
self._error = unpack_error(msg, self.chan)
|
||||
error = unpack_error(msg, self.chan)
|
||||
if (
|
||||
isinstance(error, ContextCancelled) and
|
||||
self._cancel_called
|
||||
):
|
||||
# this is an expected cancel request response message
|
||||
# and we don't need to raise it in scope since it will
|
||||
# potentially override a real error
|
||||
return
|
||||
|
||||
self._error = error
|
||||
|
||||
# TODO: tempted to **not** do this by-reraising in a
|
||||
# nursery and instead cancel a surrounding scope, detect
|
||||
|
|
Loading…
Reference in New Issue