Skip to content

Restructure Wolverine handlers into Publisher/Handler/Policy pattern with per-queue feature flags #1072

Description

@martivj

Description

Right now all ASB registration in Events lives behind one WolverineSettings.EnableServiceBus flag (Program.cs:191-224) that switches all four queues (registration, inbound, outbound, validation) on or off together, and each Commands/*.cs file mixes the handler and its retry-policy Configure(HandlerChain) in one static class. altinn-notifications solved both problems during its own Kafka→ASB migration: a Command/Publisher/Handler/Policy split per message type, plus one independent enable flag per publisher/listener (not a single master switch), so each queue's cutover — and rollback — can be controlled independently.

Only registration and subscription-validation are genuine "which transport for a new item" decision points — they're the two entry points where an item is first created. Inbound and outbound don't need an independent publish decision: they always inherit their transport from whichever pipeline produced the message (already true today — once a message is in the ASB pipeline it stays there, and vice versa for the legacy Storage-Queue pipeline), so they only need a listener flag, not a publisher flag.

Scope

  • Move the 4 command records (RegisterEventCommand, InboundEventCommand, OutboundEventCommand, ValidateSubscriptionCommand) into Wolverine/Commands/, and split each of SaveEventHandler, SendToOutboundHandler, SendEventToSubscriberHandler, ValidateSubscriptionHandler into Wolverine/{Handlers,Policies}/ files — renamed to RegistrationEventHandler, InboundEventHandler, OutboundEventHandler, ValidationEventHandler for consistent per-queue naming — following the notifications convention (IHandlerPolicy per message type, retry timing still sourced from QueueRetryPolicy on WolverineSettings).
  • Replace WolverineSettings.EnableServiceBus with 6 flags: EnableRegistrationPublisher / EnableValidationPublisher (the two real publish decisions, each getting a DI-swap-behind-interface treatment — IRegistrationEventPublisher / ISubscriptionValidationPublisher, each with an ASB and a legacy Storage-Queue implementation, selected at startup, replacing today's inline if (_wolverineSettings.EnableServiceBus) branches inside EventsService/SubscriptionService) and EnableRegistrationListener / EnableInboundListener / EnableOutboundListener / EnableValidationListener (each independently gates whether that queue's Wolverine listener is registered).
  • No separate master "enable Wolverine" flag: EnableRegistrationPublisher || EnableValidationPublisher is the single derived gate for whether ASB transport is configured at all; each listener flag still independently gates its own queue's listener registration inside that.
  • For outbound and validation, the listener flag defaults to off — the Function (Add ASB-triggered Functions for outbound delivery and subscription validation #1073) owns delivery for now — but the handler code and its listener registration must remain intact and working so a future issue can flip it on without rewriting anything.
  • Registration/inbound flags default to whatever EnableServiceBus currently resolves to per environment (no behavior change).
  • Legacy Events.Functions Storage-Queue-triggered functions are untouched and keep running unconditionally — they are not gated by any of these flags.

Out of scope

  • Building EventsAsbOutbound / the ASB-triggered validation function, and flipping any publish-flag defaults to route real traffic — that's Add ASB-triggered Functions for outbound delivery and subscription validation #1073.
  • Deleting or disabling OutboundEventHandler / ValidationEventHandler (formerly SendEventToSubscriberHandler / ValidateSubscriptionHandler) — they stay, dormant (listener flag off), until a future issue turns them back on.

Acceptance Criteria

  • Single EnableServiceBus flag removed; 2 publisher flags + 4 listener flags in place.
  • Each message type has its own Handler.cs / Policy.cs under Wolverine/; registration and validation additionally have a Publisher.cs (interface + ASB + legacy Storage-Queue implementation).
  • OutboundEventHandler / ValidationEventHandler (formerly SendEventToSubscriberHandler / ValidateSubscriptionHandler) still exist, relocated into the new structure, listener flag defaulted off.
  • No functional/behavioral change to registration/inbound — existing integration tests pass unmodified in intent (only wiring changes).

Metadata

Metadata

Labels

No labels
No labels

Projects

Status
🧪 Test

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions