Skip to content

fix(python): route event-group messages sent by the owner actor#303

Open
richardssam wants to merge 1 commit into
AcademySoftwareFoundation:developfrom
richardssam:pr/event-group-owner-routing
Open

fix(python): route event-group messages sent by the owner actor#303
richardssam wants to merge 1 commit into
AcademySoftwareFoundation:developfrom
richardssam:pr/event-group-owner-routing

Conversation

@richardssam

Copy link
Copy Markdown
Contributor

Summary

Fixes EventToPythonThreadLockerActor so messages broadcast by a C++ event
group are actually delivered to their Python subscribers, and prevents a
SIGSEGV when a subscribed actor is torn down mid-dispatch.

When a C++ event group broadcasts, the CAF sender is the owner actor
(e.g. a Playhead, Timeline, or selection actor), not the event-group actor the
Python code subscribed to. The dispatcher matched callbacks by sender address,
so those messages hit no callback and were silently dropped.

Why it matters (general, not playhead-specific)

This affects any subscribe_to_event_group() consumer. Concretely, a Python
plugin that subscribes to a timeline's change events or a viewport's
current-selection events receives nothing today, so it can't detect or forward
structure/selection changes.

Reproduced end-to-end with an external sync plugin: reverting the owner-actor
argument makes an xSTUDIO-driven add-media / select / delete-media sequence
fail to propagate to a peer (our delete_media_xstudio integration test); it
passes with the fix.

Changes

  • Track the optional owner actor per callback ID in EventToPythonThreadLockerActor.
  • Route an incoming message via the owner-actor address as a fallback when the
    sender matches no event-group key.
  • Add a broadcast_down_atom handler to purge stale callback entries when a
    subscribed owner actor dies (fixes the timeline-switch SIGSEGV).
  • subscribe_to_event_group (module.py) passes the owner actor as the 3rd arg
    to add_message_callback — backward compatible; the C++ side still accepts
    the 2-arg form.

Relationship to #270

This supersedes #270, which framed the fix around playhead events — where the
concern was that playhead event payloads carry types not bound to Python. This
version is scoped to the general event-group routing mechanism and is
demonstrated with a non-playhead case (timeline structure / selection sync)
that carries Python-friendly data. The playhead-specific Python plumbing from
#270 is intentionally not included.

Written with assistance from Claude.

Python event-group subscriptions could silently drop messages. When a C++
event group broadcasts, the CAF sender is the owner actor (e.g. a Playhead,
Timeline, or selection actor), not the event-group actor the Python code
subscribed to. EventToPythonThreadLockerActor looked up callbacks by sender
address, so those messages matched no callback and were never delivered.

This affects any subscribe_to_event_group() consumer, not just playheads.
For example, a Python plugin subscribing to a timeline's change events or a
viewport's current-selection events receives nothing, so it cannot detect or
forward structure/selection changes. Reproduced with an external sync plugin:
reverting the owner-actor argument makes an xSTUDIO-driven add/select/delete
sequence fail to propagate to a peer (our delete_media_xstudio integration
test), while it passes with the fix in place.

- Track the optional owner actor per callback ID in
  EventToPythonThreadLockerActor.
- Route an incoming message via the owner actor address as a fallback when
  the sender does not match any event-group key.
- Add a broadcast_down_atom handler to purge stale callback entries when a
  subscribed owner actor dies, preventing a SIGSEGV on timeline switches
  where the old actor is torn down mid-dispatch.
- Update subscribe_to_event_group in module.py to pass the owner actor as
  the third argument to add_message_callback (backward compatible: the C++
  side still accepts the existing 2-arg form).

Signed-off-by: Sam.Richards@taurich.org <Sam.Richards@taurich.org>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant