Let me know if you would like a test that checks the specific error messages for the different cases. Is there any relevant documentation to update for this change? I don't think it is worth adding an entry to CHANGES/ but I can do.

Codecov Report

Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 98.74%. Comparing base (3f07b1a) to head (6faaa4d).

@@            Coverage Diff             @@
##           master   #10159      +/-   ##
==========================================
- Coverage   98.75%   98.74%   -0.01%     
==========================================
  Files         122      122              
  Lines       36954    36956       +2     
  Branches     4411     4412       +1     
==========================================
- Hits        36494    36493       -1     
- Misses        313      316       +3     
  Partials      147      147              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

CodSpeed Performance Report

Merging #10159 will degrade performances by 10.92%

_{Comparing GDYendell:timer-context-error (5ad9083) with master (0070045)}

Summary

❌ 1 regressions
✅ 46 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Let me know if you would like a test that checks the specific error messages for the different cases.

Yeah, we'll want a test case for coverage.

Is there any relevant documentation to update for this change? I don't think it is worth adding an entry to CHANGES/ but I can do.

Agreed, leave it.

I'm a little confused what happened to the coverage, it says master has coverage of the existing exception, but this change doesn't have coverage of either of the exceptions...

...unless asyncio.current_task() is managing to cause a RuntimeError itself and the tests aren't checking the exception text..

...unless asyncio.current_task() is managing to cause a RuntimeError itself

Yep you're right. I have updated it to a try-except. Now the behaviour is correct. The original error case is still hit if used outside of an event loop entirely, as shown in the test. I get the new error in my application when used in the wrong event loop.

However, I am having trouble provoking the latter error case in a test, because the main event loop happens to have another task, so asyncio.current_task(loop=self._loop) does return a task, just not the one that the context manager is running in. I.e. asyncio.current_task(loop=self._loop) != asyncio.current_task(asyncio.get_running_loop())

Do you have any suggestions on how this could be done? Do you think this is now adding too much complication for the sake of an error message?

...unless asyncio.current_task() is managing to cause a RuntimeError itself

Yep you're right. I have updated it to a try-except.

Odd, the docs don't seem to suggest such behaviour.

Do you have any suggestions on how this could be done? Do you think this is now adding too much complication for the sake of an error message?

I'm not too sure how to make it work. Maybe it's not worth the effort, but I've never used multiple loops before. Up to you if you want to continue pursuing it.