Can you see in the message if it came from an error queue resubmission?
Can you provide a bit more context to your question?
You mean that if the message is retried via ServicePulse?
There are many headers available in the message to check various things:
Can you share what you want to accomplish?
– Ramon
I am trying to determine when a message is being worked if it originated from the user or from the error queue. I need to do extra processing if the message was resubmitted.
We are on version 7 of the bus using MSMQ.
How is this different compared to immediate or delayed retries? Why wouldn’t this check not be needed for these?
If it is immediate we know we have the necessary information in our database. But after 1 hour we remove the information from our database and if the message is sent back from the error queue we need to reload the information to our database again, otherwise the message will fail and go back to the error queue after xx retries.
Is that solution similar to the outbox that is offered by the Particular Platform?
Outbox does deduplication on a configurable period.
What I understand from your request is that you have a deduplication window of 1 hour for regular retries stored in a small database but when you manually retry you want that query to run against another datastore that contains all or at least a longer period of data to use as deduplication reference?
ServiceControl will add headers on a manually retry. If a header is present that starts with ServiceControl.Retry. that would indicate that message is a manually retry initiated from ServicePulse/Control.
Would that work for you?