When you say you want the saga to start operating on a specific date in the future, do you mean that it should process every message received after that point in time or that you should process every message sent after that point in time. There is no guaranteed order reading messages out of the input queue, and messages can spend time in delayed retries (or in ServiceControl) for some time so you need to be a bit careful about this.
I would not put the logic in the handler/saga unless it is related to the business function. Instead, I would look at implementing a pipeline behavior. Putting a behavior into the
IInvokeHandlersContext will allow you to detect when a given handler/saga is about to be invoked, choose to skip it based on the incoming message (i.e. comparing it’s Sent timestamp to your feature trigger timestamp), and log that fact. You can install the feature as needed and remove it once the date has passed.
Here’s a sample to get you started.
Using this approach, the messages will still be routed to the endpoint and the saga instance will be loaded. This means if a message can start a saga, it can still create the instance, even though the handler will not be called. Whether or not that’s an issue will depend on your specific case.
The messages are still handled (even if no handler is called) so they will go to your audit queue.