tree 44388a8ea8ed31fb825d59be9ae3bb0d202ec7b0
parent aa833196959e1cc5262c0d76c19308a446ef8c6e
author Nick Hill <nickhill@us.ibm.com> 1672796167 -0800
committer GitHub <noreply@github.com> 1672796167 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJjtNgHCRBK7hj4Ov3rIwAAb/oIACoM740JmFpvTsj6dyOO4k/G
 kqvZrLCHqHRyL80hf2AArdu5EgER0aShNPCF4DD6GGDArnXXvf3QB3oJP+Mte2ow
 TGL/wlODmpKX8jBlswzuOkT66VvP70IPCVKLrBDGmnTnaQn2F6hk/b70fy4fbcpK
 X54nSdAlPePY7G3uo/yVK81P3d0TlhcBzoI8VlOQrfIfPSm0AYvIYMFqyLUeHb21
 8i7ts3R2P+WwC+r4YspGWkHzuY6925HbitzpUWJ0LNKPkoaLxmJjzTORt39hyqkC
 Kc1tMAz8sNAkHTnf2ZBHjBz8FXso3pdrsVWmwuQovoEdXoVUwtrHlWpKZ2DiEqo=
 =X6UH
 -----END PGP SIGNATURE-----
 

fix: Re-raise python asyncio.CancelledErrors (#31982)

This is motivated by #31227 which I also encountered recently. I'm not familiar with the call lifecycle details, but it seems clear that there is some kind of race condition between user-initiated cancellations and other completion status updates.

If a user cancels a call before being notified of its completion, I believe it should be considered cancelled unconditionally, regardless of whether the call actually completed successfully before its cancellation status could be set.

So it seems better to re-raise explicitly rather than using self._raise_for_status(), which is a no-op in this race condition and can lead to an UnboundedLocalError.