Don't raise if the task already have been cancelled explicitly

[asvetlov]

Fixes #229

[asvetlov]

I'll try to manage the red CI on evening. Tests pass locally.

[Dreamsorcerer]

CI is failing because this unfortunately still does not fix the second case. A cancellation can still be suppressed.

[Dreamsorcerer]

I feel like there needs to be something new introduced to asyncio, so when looking at the CancelledError you can tell how many times cancel() was called before raising the exception and/or whether all cancellations were caused by us (i.e. was the sentinel sent for every cancellation).

Maybe the args on the exception could contain every msg from every cancel(). So, in these edge cases it would look like e.args == (None, _SENTINEL) from which we can see that there were 2 cancellations and only 1 was from our timeout. Then we can do a simple check like if all(msg is _SENTINEL for msg in e.args).

[Dreamsorcerer]

I find this much harder to reason about, I think it's more risky than the other solutions.

The reason this somewhat works is that it changes the call order in the before case to:
-> t.cancel()
-> Timeout._on_timeout()
-> Timeout._on_exit()
-> Timeout._cancel() # This is a noop, as it's already exited, so only 1 cancellation happens.

I'm not really sure that provides any guarantees (particularly when you have a more complex project with many tasks in flight), as it's just delaying the cancellation, which happens to be after the exit has already happened.

In the after case, this is not fixed at all (just like all the other attempts), in this case the execution looks like:
-> Timeout._on_timeout()
-> t.cancel()
-> Timeout._cancel() # Again, we've triggered 2 cancellations in a row
-> Timeout._do_exit() # No way to know there were 2 cancellations.

[Dreamsorcerer]

Raised this as a proposal: https://bugs.python.org/issue45098

[Dreamsorcerer]

Suggested change

	loop.call_at(deadline + 0.00000000001, t.cancel)
	loop.call_at(deadline + 0.000001, t.cancel)

I think you made the value so small that you've tricked your system into passing the tests by running the cancel() before the previous task. The value needs to be big enough to ensure the task is scheduled after the timeout task, but small enough that it happens immediately after without a chance to run the __exit__().

This test should be reliably failing. To verify the conditions, add prints to see when this cancel happens in relation to the timeout actions. The execution should be:
-> Timeout._on_timeout()
-> t.cancel()
-> Timeout._cancel()
-> Timeout._do_exit()

I suspect on your machine you've managed to change the execution order so t.cancel() happens first, which is what the previous test is for.