lablup / lablup/backend.ai

Refactor event dispatcher: drop source/context from callbacks and register handlers by group

Open
#13,722 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.