Modifying failed messages prior to retry

1

Hi,

Is it possible to modify the payload of a failed message in service control prior to retrying it? I took a look in raven db and modified the stored payload in there but it had no effect.

Thanks.

2

Hi Lee,

Particular Platform doesn’t currently support message modification prior to retrying.
What collection in RavenDB are you modifying?

Sean

3

I was trying to modify the failed message collection as it was the only one I found with payload in it. Where is the payload being sent in message retry stored?

4

Hi Lee,

If you modified the FailedMessage collection, that should definitely be reflected when a message is retried. That being said, it’s a little dangerous to modify the RavenDB database directly as there is no rollbacks in the case of mistakes being made. Edit: The actual message is stored as a RavenDB attachment, not the in FailedMessage collection

A better way would be to retry the messages that need changing, but to retry them to a temporary endpoint that alters the message bodies and then forwards the now-fixed messages off to the correct endpoint. The process for this would be:

  1. Create a redirect in ServiceControl for the endpoint that should process the message after it has been edited
  • E.g. A local queue called Emailer@localmachine might be redirected to EmailerCleanup@localmachine
  1. Create an app (probably a console?) with an endpoint that listens to messages from EmailCleanup
  2. Add a message mutator to mutate the incoming message to make whatever edits are required here
  3. Make the message handler forward the current message back to the Emailer queue (return context.ForwardCurrentMessageTo(“Emailer”);)
  4. Retry the message from ServicePulse. Because of the redirect the message will end up in the EmailCleanup endpoint’s queue
  5. Start the console app, which will process the message, mutate the body and headers, and then forward the now edited message to the original Emailer queue.
  6. Remove the ServiceControl redirect and stop the console application.

This ensures that the message body does not have to be manually manipulated within ServiceControl so if there are any mistakes along the way, at least the normal immediate and delayed retries mechanism will ensure the message is not lost.