Allow Wildcard based message Type mappings

[MiguelAlho]

Describe the feature

It would be useful to have more complex type mappings, based on regex, wildcards, or prefix concepts, to allow implementation of generic handlers that can ignore unsupported message types.

Use Case

I'm using the library to process GitHub events that are being placed on a SQS queue. The events are wrapped in a CloudEvent envelope as described in https://github.com/cloudevents/spec/blob/main/cloudevents/adapters/github.md

When configuring GitHub apps, the selection of event types emitted is a bit wider than what my application needs. For instance, I case about release.published events, but the GitHub App Webhook mechanism is setup to seen all types of Release events. I care to register in my .Net service a IMessageHandler for a ReleasePublishedEvent, and can do so with :

x.AddMessageHandler<ReleasePublishedMessageHandler, ReleasePublishedEvent>("com.github.release.published");

If an event of other types enters the queue (such as a release.unpublished), because there is no defined type or mapping for it, it becomes a poison message on the queue and blocks the processing.

Having a Fallback Handler, or a mechanism to suggest that any com.github.release.* type (or event wider com.github.* or even a catch_all *) can be processed by some generic Message handler or Ignore Handler would be great.

Proposed Solution

A few options i can suggest:

• Add a configuration mechanism to allow Ignoring Unmapped types . Similar to Immediate Dead letter option #165 it could be along the lines of :

x.IngoreMessagesForUnmappedTypes();

Which in needed could end up producing a MessageProcessStatus.Success(); . It would skip without "polluting" a DLQ.

• Support a wildcard or prefix based mapping:

x.AddMessageHandler<MyOtherFallbackMessageHandler, GenericRepoDispatchEvent>(WildCardMapping.From("com.github.repository_dispatch.*"));
x.AddMessageHandler<MyFallbackMessageHandler, UnknownEvent>(PrefixMapping.From("com.github."));

This could be a mechanism to use a message handler on a more generic event type (Envelope with a dynamic data payload, for instance). Exact type mappings would have precedence, over this, though (or registration order)?

• Extension mechanisms on the EnvelopeSerializer / MessageSerializer to override the decision mechanisms, and allow implementers to inject new decision elements. BTW, is this already supported in any capacity?

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS.Messaging (or related) package versions

AWS.Messaging 1.0.1

Targeted .NET Platform

.NET 8 +

Operating System and version

Linux Containers

[MiguelAlho]

Workaround at the moment, due to lack of support in the library is:

1 - Create an application specific implementation of IMessageConfiguration, that essentially decorates the IMessageConfiguration already registered. All methods and properties except GetSubscriberMapping(string messageTypeIdentifier) are routed to the decorated instance.
2 - In the app specific implementation, implement GetSubscriberMapping(string messageTypeIdentifier) with, for instance:

public SubscriberMapping GetSubscriberMapping(string messageTypeIdentifier)
    {
        var directMapping = defaultMessageConfiguration.GetSubscriberMapping(messageTypeIdentifier);
        if (directMapping != null)
            return directMapping;

        //TODO consider fallbacks for other sources
        return new SubscriberMapping(
            typeof(DefaultGithubEventHandler),
            typeof(DefaultGitHubEvent),
            "com.github.unknown-event");
    }

DefaultGithubEventHandler is a my fallback handler, DefaultGitHubEvent just implements Octokit's WebHookEvent type to have the common properties, and the type identifier is set to be clear on intent.

3 - Register the handler and the Decorator:

builder.Services.AddAWSMessageBus(x =>
        {
           x.AddSQSPoller($"https://..." );

            //load supported message handler
x.AddMessageHandler<ReleasePublishedMessageHandler, ReleasePublishedEvent>("com.github.release.published");
            //...
            //load fallback handler
            x.AddMessageHandler<DefaultGithubEventHandler, DefaultGitHubEvent>("com.github.unknown-event");
        });

        //register custom IMessageConfiguration as a decorator (using Scrutor)
        builder.Services.Decorate<IMessageConfiguration, MyCustomMessageConfiguration>();
        return builder;
}