I think it should always be quiet. If a developer wants to log them in some task, they can always explicitly catch CancelledErrors, log, and then immediately re-raise them.

Maybe a better (and backwards/forward) compatible code here would be this:

try:
  future.result()
except asyncio.CancelledError:
  raise
except Exception:
  ...

This path is for when an exception is raised after the original caller is no longer present (because of a timeout). There's nowhere else for someone to catch exceptions that make it here. All we can do is log it or not.

Tornado has an uneasy relationship with cancellation, since we never supported it until it started creeping in accidentally with asyncio integration. I still tend to think of it as weird and exceptional (because tornado will never cancel anything), but maybe that's the wrong way to look at it and we should just make CancelledError always quiet here.

This path is for when an exception is raised after the original caller is no longer present (because of a timeout).

Got it. I think making them quiet is the right thing to do. After a timeout there is no useful information that a logged CancelledError can provide.