Jump to a problem, path or page
Jump to a problem, path or page
Updates as you edit. Run the review to record it; passing every check completes the problem.
Not yet passed: Publisher responsibility
Add Publisher and define its responsibility.
Not yet passed: Event bus responsibility
Add Event bus and define its responsibility.
Not yet passed: Subscription registry responsibility
Add Subscription registry and define its responsibility.
Not yet passed: Dispatcher responsibility
Add Dispatcher and define its responsibility.
Not yet passed: Listener responsibility
Add Listener and define its responsibility.
Not yet passed: Error handler responsibility
Add Error handler and define its responsibility.
Not yet passed: Publisher → Event bus
A directed path must connect Publisher to Event bus. Arrows represent requests, dependencies, or event flow.
Not yet passed: Event bus → Subscription registry
A directed path must connect Event bus to Subscription registry. Arrows represent requests, dependencies, or event flow.
Not yet passed: Event bus → Dispatcher
A directed path must connect Event bus to Dispatcher. Arrows represent requests, dependencies, or event flow.
Not yet passed: Dispatcher → Listener
A directed path must connect Dispatcher to Listener. Arrows represent requests, dependencies, or event flow.
Not yet passed: Dispatcher → Error handler
A directed path must connect Dispatcher to Error handler. Arrows represent requests, dependencies, or event flow.
Not yet passed: Which subscriptions receive a publication?
Not yet passed: What if one listener throws?
Not yet passed: What should unsubscribe(token) do twice?
Not yet passed: Interfaces and invariants
Write at least 80 characters describing concrete operations, inputs, outputs, state and errors. This check measures completeness, not semantic correctness.
Not yet passed: Trade-offs and failure cases
Write at least 80 characters about alternatives, failure handling and edge cases. Review the reasoning yourself using the reference discussion.
Rule-based educational feedback. Notes are checked by length only; topology checks confirm directed reachability. These checks do not validate semantics, latency, reliability or every valid design.
Use a token-indexed subscription registry and a dispatcher that iterates a stable snapshot in registration order. Isolate listener failures and define synchronous, reentrant and optional asynchronous behavior explicitly. Subscribe validates the topic/callback and stores a new token with a monotonically increasing registration order. Duplicate callback subscriptions remain separate registrations. Publish captures the topic’s subscriptions before invoking user code. Treat event payloads as immutable supported values; snapshot or freeze them according to the library’s explicit payload contract. Invoke snapshot listeners in registration order. Catch each listener error, collect it in PublishResult and report it through a guarded error handler. Error-handler failures are collected without recursive event publication. Unsubscribe removes exactly one token and is idempotent. Enforce a nesting-depth limit for synchronous reentrant publish. If async delivery is added, bound its queue and return an overload result when full.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.