Ignore child events in adaptors

[gselzer]

Currently, adaptors receive updates from changes to their own backing model via Adaptor.handle_event. Once this listener is set up, setting a field of the model to some other evented class will relay child events back to the parent.

Take, for example, a scenex Camera. If you make an adaptor for that camera, and then later set its controller to an Orbit, updating its center will relay that update to the Camera. Before these changes, that would log an error, because the Camera adaptors don't have a _snx_set_center method, nor should they.

I could foresee the relay being useful, so for now, if a relay occurs (checked here using EmissionInfo.path), we'll just log a debug message when the adaptor doesn't have the child

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates adaptor event handling to ignore relayed “child” events that bubble up to a parent model when the parent adaptor doesn’t implement a corresponding setter, avoiding erroneous AttributeErrors while still logging useful debug info.

Changes:

• Detect bubbled/relayed events via EmissionInfo.path length and ignore them when no setter exists.
• Add debug logging describing the ignored nested event path and value.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

info.args[0] can raise IndexError if an emission occurs with no positional args (even if uncommon). Since this value is only used for logging and passing to the setter, consider guarding (e.g., check info.args length) or using a safe fallback before indexing.

[tlambert03]

Feel free to proceed. But this does have a faint smell to me. Is the camera controller the very first field for which this applies? Are you confident that this diversion from the original model (in which fields on the model corresponded to things that an adapter would genuinely need to respond to) is a generally useful future direction that warrants ignoring what used to be a smell? The alternative here of course is just to keep the original model and explicitly just add the set center method as a no-op. (I.e. maybe we shouldn't be so sure that they shouldn't have that method after all...).

Haven't thought my way through all this, and haven't foreseen the next case where you might want to ignore it again: just noting what seems like a possible smell

[codecov]

Codecov Report

❌ Patch coverage is 20.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.97%. Comparing base (d5236c4) to head (f0b72b5).

Files with missing lines	Patch %	Lines
src/scenex/adaptors/_base.py	20.00%	4 Missing ⚠️

❌ Your patch check has failed because the patch coverage (20.00%) is below the target coverage (85.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #73      +/-   ##
==========================================
- Coverage   88.09%   87.97%   -0.12%     
==========================================
  Files          64       64              
  Lines        3174     3178       +4     
==========================================
  Hits         2796     2796              
- Misses        378      382       +4     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gselzer]

Is the camera controller the very first field for which this applies?

Actually, no! I just never encountered it before because it's a code path we don't often encounter in scenex, but the camera controller seems uniquely vulnerable to this. Most of our models are insulated from this because they use EventedLists to store children (Nodes with child Node, Canvases with their Views) - the Camera is really the main place it can happen, but hypothetically all Camera fields are also vulnerable, in addition to any Controller fields. For example:

import scenex as snx

# Create a view
view = snx.View()
# Create the adaptor to add a listener
view._get_adaptors(create=True)
# Call setattr
view.camera = snx.Camera(interactive=True)
# Update the child
view.camera.interactive = False  # LOGS AN ERROR

Logs out:

'View' object has no attribute '_snx_set_interactive'
Traceback (most recent call last):
  File "C:\Users\gjselzer\code\pyapp-kit\scenex\src\scenex\adaptors\_base.py", line 56, in handle_event
    setter = getattr(self, name)
AttributeError: 'View' object has no attribute '_snx_set_interactive'

Are you confident that this diversion from the original model (in which fields on the model corresponded to things that an adapter would genuinely need to respond to) is a generally useful future direction that warrants ignoring what used to be a smell?

Well, no 😆

I actually had an idea recently for an organizational structure that you might like better. More to come soon on that!