Simplify event loop handling and remove deprecated get_event_loop#340
Simplify event loop handling and remove deprecated get_event_loop#340
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR removes explicit event loop parameters from the FastCS API and internal implementations, replacing manual loop passing with implicit asyncio patterns such as Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can generate a title for your PR based on the changes.Add |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/fastcs/control_system.py`:
- Around line 54-55: The code currently installs SIGINT/SIGTERM handlers inside
serve(), which hijacks signal handling when serve() is called from an existing
async runtime; move the signal-handler installation out of serve() and into
run() so handlers are only installed when run() is explicitly invoked, and guard
the installation with a main-thread check (threading.current_thread() is
threading.main_thread()) and ensure the event loop supports add_signal_handler
before calling it (e.g., get the loop from asyncio.get_event_loop() and call
add_signal_handler only when permitted). Modify serve() to no longer call
add_signal_handler, and update run() to install the handlers conditionally for
SIGINT/SIGTERM using the same handler functions currently referenced in serve().
- Around line 164-167: The interactive_shell task created inside run()/wrapper
must be tracked and its exceptions handled: when creating the coroutine
(interactive_shell / asyncio.to_thread(partial(shell.mainloop, ...))) retain the
Task returned by asyncio.create_task and attach a done callback that
catches/logs exceptions and always calls stop_event.set() on error; also ensure
tasks spawned by run() are appended to a local registry so failures are visible
(e.g., add the created Task to a list in run() and on completion remove it), and
update wrapper to create the task via that helper so any raised exceptions won't
silently block await stop_event.wait().
In `@tests/transports/tango/test_dsr.py`:
- Around line 58-71: The current finally block's cleanup iterates
gc.get_objects() and closes any asyncio.AbstractEventLoop it finds, which is
unsafe; change the cleanup to only close loops created by this test/context by
recording references to event loops you create (e.g., the 'loop' variable and
any loops returned or owned by DeviceTestContext) or by snapshotting existing
loops before entering DeviceTestContext and closing only loops that appear
afterwards, and remove the gc.get_objects() iteration; ensure you still call
loop.run_until_complete(asyncio.sleep(0)), loop.close(),
asyncio.set_event_loop(None) and gc.collect() but limit any additional .close()
calls to the specific loop objects you tracked rather than all AbstractEventLoop
instances.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: cc07bde6-a8ed-470a-a36d-83ba46c30250
📒 Files selected for processing (16)
src/fastcs/control_system.pysrc/fastcs/launch.pysrc/fastcs/transports/epics/ca/ioc.pysrc/fastcs/transports/epics/ca/transport.pysrc/fastcs/transports/epics/pva/transport.pysrc/fastcs/transports/graphql/transport.pysrc/fastcs/transports/rest/transport.pysrc/fastcs/transports/tango/transport.pysrc/fastcs/transports/transport.pytests/benchmarking/controller.pytests/test_control_system.pytests/transports/epics/ca/test_initial_value.pytests/transports/epics/pva/test_p4p.pytests/transports/graphQL/test_graphql.pytests/transports/rest/test_rest.pytests/transports/tango/test_dsr.py
💤 Files with no reviewable changes (1)
- tests/transports/epics/ca/test_initial_value.py
676fac5 to
e8b2558
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## docs #340 +/- ##
==========================================
- Coverage 91.21% 90.98% -0.23%
==========================================
Files 70 70
Lines 2594 2596 +2
==========================================
- Hits 2366 2362 -4
- Misses 228 234 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
e8b2558 to
941e46b
Compare
941e46b to
d9d0620
Compare
In the process of writing documentation it became clear that
Summary:
loopparameter toFastCSand instead require clients to callservefrom an async context with the loop they want it to run inloopto transports and instead retrieve it viaget_running_looponly where required (EpicaCA and Tango)asyncio.create_taskfrom an async context consistently in tests, rather thanrun_until_completeorensure_futureSummary by CodeRabbit