Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.47k stars 4.8k forks source link

[FEATURE REQ] Ability to skip handler execution in ServiceBusProcessor with PeekLock and Prefetch #31966

Closed danielmarbach closed 2 weeks ago

danielmarbach commented 2 years ago

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

jsquire commented 2 years ago

Thank you for your feedback. Tagging and routing to the team member best able to assist.

JoshLove-msft commented 2 years ago

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
}
danielmarbach commented 2 years ago

@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

SeanFeldman commented 2 years ago

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.

jsquire commented 1 year ago

I'm going to shift this over to a feature request and put it on the backlog for consideration.

github-actions[bot] commented 2 weeks ago

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.