Detecting last Delayed Retry in Command Handler

Architecture & Design
#1

Hi,
I may be approaching this incorrectly but I have a simple CommandHandler on an endpoint (the endpoint has a number of different command handlers)
When the processing in the handler fails for some reason, I’d like to know whether there are more retries or whether this is the last attempt
e.g. set a status to pending if still retrying or failed if its the last retried failure (for publishing via an event),
I know there are notifications which can be subscribed to on the endpoint but I was hoping to have all the logic confined and isolated in its own commandhandler

Any pointers or guidance would be greatly appreciated
Alan

#2

Hi Alan:

Unfortunately not. Perhaps with more details, I could suggest a solution. If you would like me to reach out to schedule a call let me know.

Bob

#3

Thanks for your reply Bob, it’s much appreciated
I am in Australia so am guessing the timezones don’t really work for us that well
We have a scenario where for example we create a user enquiry in our system. After doing whatever it has to do successfully, an event is published onto an integration endpoint. This handler then works out various integration points and send commands to different endpoints so that different API’s are called on various different external systems, each with their own microservices to handle the integration for their specific api.
Some of the processing may immediately be successful. some may be successful on various immediate/delayed retries and others may fail after multiple delayed retries
Each endpoint has their own different circuit breaker error policy. e.g. some only allow an hour to fail. Others will retry for up to 24 hours
On failure each handler will throw an ExternalIntegrationException, which I can subscribe to this at an endpoint level.
However, depending on the type of integration, I may want to send a notification back to the user notifying it failed and that we are continuing to retry in background. On the final retry failure we will then update the status of an entity and send an email to the user indicating they should retry. Others are handled by internal monitoring of the error queue. Each integration point has its own error handling scenario, some failing fast and some able to retry over an extended period.

Hope this makes sense

#4

P.S. Further to this, do you have a suggestion for raining error notifications in this scenario? Normally we would publish a failedevent which a WebAPI can subscribe to and notify the user, but throwing an exception in the CommandHadndler (to invoke the delayed retries) rolls back any events that we have published as part of the commandhandler, correct?

#5

It makes sense.

You can send/publish messages with the immediate dispatch option. It ignores the whole batch/transactional message dispatch and sends it out right now. This is great for scenarios when contextually it doesn’t matter if the processing of the incoming message is successful.

Also, remember that publish uses PublishOptions instead of SendOptions, but the configuration is the same.