BrighterCommand / BrighterCommand/Brighter

Subscription should route via the request type

Open
#4,266 0 comments 0 reactions 0 assignees View on GitHub
.NET 0 - Backlog Bug V10.X
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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.