Correct way to map cloud events type to request type

[dssldavidmorgan]

I set up my RmqSubscription objects like below, so that a cloud events type string maps to a Type which is a request type. The getRequestType gets the associated type from the message's cloud events type header and returns null if it's not found.

What I want to know is how I should handle the case where there may be message types received that the service isn't interested in consuming.

Currently, the getRequestType method signature doesn't accept a null value returned, and it logs a noisy warning whenever a message type is received that doesn't have a handler.

var messageTypes = subscriptions.ToDictionary(x => x.Type, x => x.RequestType);

var rmqSubscriptions = subscriptions.ConvertAll(x => new RmqSubscription(
    ...
    getRequestType: message => messageTypes.TryGetValue(message.Header.Type.Value, out var messageType) ? messageType : null!,
    ...));

In both the Proactor and the Reactor the getRequestType function is used like this:

var requestType = _mapRequestType(message);
if (requestType == null)
    throw new MessageMappingException($"Failed to find request type for message {message.Id} ", 
        new ArgumentNullException(nameof(requestType), "The request type cannot be null."));

It expects that requestType might be null, although the signature doesn't suggest that it should return null, and it always throws an exception, which gets logged as a warning. Useful if you've made a configuration error, but noisy if you just want to ignore certain message types.

[lillo42]

Maybe @iancooper has an alternative, but for V10, you must return something; we are expecting that you consume the message. What you could do is create IgnoreRequest and process the message like

public class IgnoreRequest : Event() { ... }

public class IgnoreRequestHandler : RequestHandler<IgnoreRequest>
{
   ....
   public IgnoreRequest Handle(IgnoreRequest request) { return request; }
}

[iancooper]

So the null handler proposed by @lillo42 is a good idea, so if you don't want the log, just do as Rafa suggests.

I would be against using silent failure as the default, and if it's not expected, I would tend to route this message to a DLQ or an invalid message queue. So I suspect we would want some way to offer deliberate fall-through. That might mean we need to switch to an Option or similar for the result that lets you indicate null without throwing.

As that would be a breaking change, we would not act on it until V11, so for now, I would use an Ignore Handler