BrighterCommand / BrighterCommand/Brighter
Subscription should route via the request type
- Dominant language
- C#
- Stars
- 2.5k
- Forks
- 296
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 21
Description
**Is your feature request related to a problem? Please describe.**
Brighter differentiates between a Command - a single handler and an event - zero or more handlers. When we receive a message via the MessagePump and forward it to handlers via the CommandProcessor, we do this based on the message type header, MT_COMMAND (commands) or MT_EVENT (event).
As a result, we consider it an error to map a message_type of MT_COMMAND to an Event-derived type, and vice versa.
When we are sent a message without a message type, typically from a 3rd-party framework, we default to MT_EVENT.
This causes a bug if the subscriber wishes to interpret a 3rd-party framework event as a command.
**Describe the solution you'd like**
We MUST determine whether the type the mapper returns derives from Command or Event and route accordingly. We SHOULD ensure in ValidatePipelines that you derive all of your IRequest implementations from Command or Event; it's theoretically an error anyway, but we should enforce it there. We SHOULD change the subscription so that it looks at the type of the event for the Subscription, which we have anyway, and sets the default (MT_EVENT or MT_COMMAND) for the subscription where the header did not exist.
This would allow us to continue to pick up a mismatch: you send an MT_COMMAND, and I read it as an MT_EVENT. The problem here may be proposals like Kafka Queues, which would always be raised as an MT_EVENT but could be read as an MT_COMMAND, so we should probably remove the constraint that you must match the message type header.
This means that the message type header has no value and MUST be marked obsolete and MAY BE removed in a future release.
Contributor guide
Research direction
Start by tracing message handling from MessagePump through CommandProcessor and inspect ValidatePipelines and Subscription handling for IRequest, Command, and Event types. Determine the intended routing and validation behavior for missing or mismatched message type headers, then confirm that third-party events can be interpreted as commands without losing useful mismatch detection.】【。}
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend-api-design, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100