fix(mcs_card): handle excess data points and improve MCA callback suppression #308

2026-09-05T13:04:51+02:00

wakonig_k commented

2026-09-05 13:04:51 +02:00

The MCS card emits MCA updates while erasing. A suppression mechanism prevents these updates from leaking into scan data, but its locking logic contained a bug.

Previously, the suppression mechanism held the data lock, preventing pending callbacks from running and being discarded. Once suppression ended, those callbacks could be processed as scan data. This change releases the lock during suppression, allowing callbacks to run, detect suppression, and discard their data.

Additionally, completion now fails immediately with a clear error if more points are received than expected.

The MCS card emits MCA updates while erasing. A suppression mechanism prevents these updates from leaking into scan data, but its locking logic contained a bug. Previously, the suppression mechanism held the data lock, preventing pending callbacks from running and being discarded. Once suppression ended, those callbacks could be processed as scan data. This change releases the lock during suppression, allowing callbacks to run, detect suppression, and discard their data. Additionally, completion now fails immediately with a clear error if more points are received than expected.

wakonig_k added 1 commit 2026-09-05 13:04:51 +02:00

fix(mcs_card): handle excess data points and improve MCA callback suppression

CI for csaxs_bec / test (pull_request) Successful in 1m45s

Details

Read the Docs Deploy Trigger / trigger-rtd-webhook (push) Successful in 1s

Details

CI for csaxs_bec / test (push) Successful in 1m43s

Details

4c53f2cf25

wakonig_k requested review from menzel 2026-09-05 13:05:01 +02:00

menzel commented

2026-09-08 13:32:13 +02:00

The docstring NOTE (lines 60–63) says _omit_mca_callbacks "will remain set after exiting the context" — only true for restore_after_timeout=None. Since the whole change is about subtle locking, it would be worth stating there, not just in the inline comment, that the lock is deliberately not held across the body.
2. suppress_mca_callbacks doesn't clear _current_data, so a suppression starting mid-batch leaves a partial dict that merges with the next batch. Every current call site happens to be covered by its caller, so it isn't live — but clearing it under the lock alongside setting the flag would make the context manager self-sufficient.

The docstring NOTE (lines 60–63) says _omit_mca_callbacks "will remain set after exiting the context" — only true for restore_after_timeout=None. Since the whole change is about subtle locking, it would be worth stating there, not just in the inline comment, that the lock is deliberately not held across the body. 2. suppress_mca_callbacks doesn't clear _current_data, so a suppression starting mid-batch leaves a partial dict that merges with the next batch. Every current call site happens to be covered by its caller, so it isn't live — but clearing it under the lock alongside setting the flag would make the context manager self-sufficient.

menzel merged commit 4c53f2cf25 into main

2026-09-08 13:32:36 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bec/csaxs_bec#308