Refactor event dispatcher: drop source/context from callbacks and register handlers by group
- Dominant language
- Python
- Stars
- 670
- Forks
- 183
- Avg merge
- 17h 7m
- Merged PRs (30d)
- 358
Description
### Background
Follow-up requested in the review of the Pydantic event payload work. The three steps below are ordered deliberately: each one makes the next possible.
### 1. Remove source and context from the callback signature
- `context` is `None` at 76 of 86 registrations, and handlers ignore it — they are already objects holding their own dependencies. It can go directly.
- `source` cannot. 16 of 18 callbacks use it as a domain identifier, e.g. `HandleHeartbeatAction(agent_id=source)`. Move the producing node identity into the event body as a field first, then remove the parameter. Adding a field is cheap now that events are Pydantic models, and unknown fields are ignored on read, so producers and consumers can cut over in any order.
### 2. Register handlers by domain group
Replace the flat list of about 75 `consume()` / `subscribe()` calls in the manager dispatch module with per-domain groups, shaped like the service processor groups: a class declaring its own event-to-handler mapping as typed fields, with the shared wiring applied by the group. `EventDispatcherGroup` already exists but currently only injects reporters.
### 3. Enforce one handler per event at registration
The `consume()` docstring promises that when several callbacks register for one event, only one of them is called. The implementation does the opposite: handlers go into a set and every one of them is dispatched, with the ack waiting for all. An anycast event registered twice is therefore processed twice, which contradicts the delivery pattern. Enforce uniqueness at registration so the guarantee holds structurally rather than by convention.
### Depends on
The event-type registry issue. Step 3 is natural once a group declares one handler per event against a known set of event types.
JIRA Issue: BA-7342
Contributor guide
Research direction
Start in the manager dispatch module, reviewing the existing consume()/subscribe() registrations and EventDispatcherGroup, then inspect the event-type registry issue it depends on. Trace the 18 callbacks that use source and the event producers before changing callback inputs. Done means domain identity is carried in event bodies, handlers are grouped by domain, and duplicate anycast handlers are rejected at registration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100