IfCondition.notify() raises an exception thatcould have occurredafter the task was selected to be woken up, wake up another task instead, if available.

This ensures that the typical case, of waking upone task to handle something, will succeed even if the candidate task
is cancelled at the same time or otherwise wakes up with an error.

Thismay result in a spurious wakeup of a waiting task, which is what the Condition Variable protocol specifies, precisely because waking up tasksconservatively (rather wake up too many than too few) is the safest and simplest to implement, and missing wakeups are serious (and cause deadlocks), while extra wakeups are easily handled by application code.

IMHO trying to guarantee that we never perform any extra wakeups would complicate the code too much and be too hard to verify, particularly since that is not a guarantee that Condition Variables are supposed to provide.

The PR includes

• Tests
• Fix to asyncio.Condition where raising an exception out ofcondition.wait after having released the lock will result in a second task being awoken, if available
• Documentation changes explaining the Condition Variable protocol and how if favors too many wakeups over to few wakeups (i.e. how "spurious wakeups"may occur)

📚 Documentation preview 📚:https://cpython-previews--112201.org.readthedocs.build/

• Issue:Race between asyncio Condition.notify() and Task.cancel() may result in lost wakeups. #112202