More control over abandoned messages about azure-service-bus-dotnet

[HansOlavS]

+1 from me.

It's a non-trivial thing to do this unless you're using the built-in lock time of the message and simply not abandoning it (so it times out and is picked up again). This method has several drawbacks because you can only have 7 minutes lock time (sometimes you want to wait longer before retrying) and a message also has a max retry count (sometimes you want to retry within a time frame and don't care so much about the number of retries).

To be honest I don't really understand where Defer() would be safe to use if it's not combined with a permanent store like a database. If you defer a message and your VM/App is recycled you lose that message forever.

Defer(TimeSpan) or Defer(ScheduleteTimeUtc) sounds perfect. Or maybe a separate method like Reschedule(ScheduleTimeUtc).

[SeanFeldman]

Great suggestion. Also would cut down amount of work that has to be done today on the client-side to get a workaround.

[ddobric]

Regarding Defer(), you are right. But this is an additional required improvement. Defer introduce more problems than it helps, in that case. My intension around Abandon() is to provide us features, which do not require so much programming and introducing additional artifacts like DB.
With Deffer(TimeSpan), I mean postponing of the message at scheduled time, without of need to keep reference of it.

[SeanFeldman]

@binzywu it introduced overhead that needs to be taken into consideration and coded each time. Because it's no longer a single message based operation, you need to have a transaction. Rather than just using Defer(timespan).
Also, from a tracking point of view, you want to handle the same message, just later. Saying that, @djrosanova made a good point saying that ASB doesn't mutate messages. But in this case, it would not be exactly a mutation, if broker is instructed to defer the processing.

[SeanFeldman]

@jtaubensee I think you wanted to link to issue #6? 😉

[nemakam]

This issue has been added to milestone backlog. Given that we haven't planned for this feature yet, it might not be right to assign 2.0 milestone for this issue yet.

[SeanFeldman]

I'll need this feature as it will be blocking for scenarios where a message needs to be delayed and the original message ID has to be kept, but native-dedup is in place. A workaround suggested here

Complete the message and schedule another message for 5 mins later.

would not work.

[gdodd1977]

What is the latest on this feature? This seems like a no-brainer feature for queue work.
Thanks.

[binzywu]

can this be achieved by re-send the current messages as scheduled messages and complete the current message?

[jtaubensee]

@ddobric - This is something that we can revisit when both .NET Core and AMQP support transactions. We could easily implement a method to do what you are talking about. We would create a transaction, complete the message, and send a scheduled message.

[SeanFeldman]

Would this be considered for 1.0.0 or later?

[nemakam]

Like mentioned here , this would require AMQP transactions to be implemented first. Unfortunately, this would not make it to 1.0.0.

[SeanFeldman]

Thanks @nemakam. Skipped that comment. So it could be then added to the 2.0.0 milestone or 2.x in case it has to be done after #6 is finished.

[SeanFeldman]

Server side work is tracked here.

[DanCaveman]

We need this feature as well. I am trying to stay with a Microsoft stack, but it is difficult when the applications have to manage the scheduling and DLQ to get functionality that would be solved with a Defer(datetime) or Defer (timespan). Without it, the automatic DLQ functionality is not useful and we had to code logic to know when to dead letter a message.