You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
Description
Right now all ASB registration in
Eventslives behind oneWolverineSettings.EnableServiceBusflag (Program.cs:191-224) that switches all four queues (registration, inbound, outbound, validation) on or off together, and eachCommands/*.csfile mixes the handler and its retry-policyConfigure(HandlerChain)in one static class.altinn-notificationssolved both problems during its own Kafka→ASB migration: aCommand/Publisher/Handler/Policysplit 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
RegisterEventCommand,InboundEventCommand,OutboundEventCommand,ValidateSubscriptionCommand) intoWolverine/Commands/, and split each ofSaveEventHandler,SendToOutboundHandler,SendEventToSubscriberHandler,ValidateSubscriptionHandlerintoWolverine/{Handlers,Policies}/files — renamed toRegistrationEventHandler,InboundEventHandler,OutboundEventHandler,ValidationEventHandlerfor consistent per-queue naming — following the notifications convention (IHandlerPolicyper message type, retry timing still sourced fromQueueRetryPolicyonWolverineSettings).WolverineSettings.EnableServiceBuswith 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 inlineif (_wolverineSettings.EnableServiceBus)branches insideEventsService/SubscriptionService) andEnableRegistrationListener/EnableInboundListener/EnableOutboundListener/EnableValidationListener(each independently gates whether that queue's Wolverine listener is registered).EnableRegistrationPublisher || EnableValidationPublisheris 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.EnableServiceBuscurrently resolves to per environment (no behavior change).Events.FunctionsStorage-Queue-triggered functions are untouched and keep running unconditionally — they are not gated by any of these flags.Out of scope
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.OutboundEventHandler/ValidationEventHandler(formerlySendEventToSubscriberHandler/ValidateSubscriptionHandler) — they stay, dormant (listener flag off), until a future issue turns them back on.Acceptance Criteria
EnableServiceBusflag removed; 2 publisher flags + 4 listener flags in place.Handler.cs/Policy.csunderWolverine/; registration and validation additionally have aPublisher.cs(interface + ASB + legacy Storage-Queue implementation).OutboundEventHandler/ValidationEventHandler(formerlySendEventToSubscriberHandler/ValidateSubscriptionHandler) still exist, relocated into the new structure, listener flag defaulted off.