Closed danielmarbach closed 2 weeks ago
Thank you for your feedback. Tagging and routing to the team member best able to assist.
Interesting, is the idea that you would want to key off of the LockedUntil property @danielmarbach?
I assume the workaround is to do something like:
async Task ProcessMessage(ProcessMessageEventArgs args)
{
if (args.Message.LockedUntil < DateTimeOffset.UtcNow)
{
return;
}
// do stuff if the lock is still valid
}
@JoshLove-msft yep exactly. The workaround is rather simple like you showed. I was just thinking that the processor could take care of this since it is a higher level abstraction
That's a good idea, especially for the misconfigured consumer that gets to the messages well after they have lost their lock token. I'd suggest one addition to the processor - an event indicating what message has been skipped due to a lost lock token. When an event about skipped processing messages is raised, it could be locked to shed light on how bad of a problem it is and help instrument the configuration/code.
I'm going to shift this over to a feature request and put it on the backlog for consideration.
Hi @danielmarbach, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.
Library name
Azure.Messaging.ServiceBus
Please describe the feature.
Currently the ServiceBusProcessor always executes the processing handler. With PeekLock and Prefetch it is though possible that the message has already exceeded the peek lock duration when the processing handler is called. In such a scenario the event handler logic would be executed only to then actually figure out the lock has already been lost.
It would be great if there would be a mode when the event handler execution is skipped and the message abandoned when the peek lock is already over. Given that is a breaking change in behavior, I guess this should be opt-in on the processor options.
Although you could argue invoking the handler in such a case really doesn't make much sense since the only outcome is the message lock has already been lost