When renaming or translating message types, for example from Dutch to English, there is no built in way to map old message types to new ones. This makes it hard to handle existing or in flight messages without keeping both contracts around.
Current workaround
Keep the old message type and add a second handler that maps to the new type using cascading messages:
public static NewMessage Handle(OldMessage message)
{
return new NewMessage
{
// map fields
};
}Wolverine will automatically publish the returned message as a cascading message.
This works, but:
- requires keeping duplicate message types
- adds extra handlers purely for translation
- clutters the codebase during migrations
Expected behavior
- ability to map or alias old message types to new ones
- allow multiple message names to resolve to the same handler or CLR type
Why this matters
Message contracts evolve regularly. This should not require temporary duplication and extra handlers just to keep compatibility during a rollout.
Happy to provide an example if helpful.
When renaming or translating message types, for example from Dutch to English, there is no built in way to map old message types to new ones. This makes it hard to handle existing or in flight messages without keeping both contracts around.
Current workaround
Keep the old message type and add a second handler that maps to the new type using cascading messages:
Wolverine will automatically publish the returned message as a cascading message.
This works, but:
Expected behavior
Why this matters
Message contracts evolve regularly. This should not require temporary duplication and extra handlers just to keep compatibility during a rollout.
Happy to provide an example if helpful.