SDK type support for Service Bus

[SeanFeldman]

There's already an existing issue somewhat related to my question but doesn't cover it entirely.

1. What Service Bus SDK is going to be supported with .NET isolated worker? Will it be Azure.Messaging.ServiceBus?
2. What's the plan for supporting SDK type in the trigger? string body is not what I need.

[fabiocav]

The current extension just installs this extension in the host: https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.ServiceBus/

Which uses Microsoft.Azure.ServiceBus.

Service Bus types support will land as we iterate, for now, the native types (non-SDK types) should be supported (string, byte[], POCOs)

[SeanFeldman]

@fabiocav, byte[] will work for the body but not the headers. What would be the recommended way to retrieve the incoming message headers?

[onionhammer]

@SeanFeldman looks like you can retrieve this from FunctionContext;
context.BindingContext.BindingData.TryGetValue("Label", out var label)

[fabiocav]

Indeed; that wasn't in the last preview, so it's a property that only became publicly available in the final release (sorry about that).

We actually had this thread on the radar to update with that information and, because of that, the BindingContext property was often referred to as "Sean's property".

It's also worth mentioning that, similar to WebJobs/Functions, method parameters matching the binding data names should also be automatically bound, so that's another option if you don't want to work directly with the context.

[SeanFeldman]

We actually had this thread on the radar to update with that information and, because of that, the BindingContext property was often referred to as "Sean's property".

😺

[MartinWickman]

Previously, you could get the MessageReceiver as input parameter to the function. Is MessageReceiver (or equivalent) available in the context as well? Also, where is this stuff documented?

[fabiocav]

@MartinWickman MessageReceiver, as mentioned above, that isn't one of the types supported with the OOP model today.

Public documentation for the worker model is available here: https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide

[SeanFeldman]

Once the 1.0 pressure is off (if it ever happens) would it be possible to discuss the future roadmap for Service Bus trigger?

Having access to MessageReceiver allows more advanced scenarios that are just not possible with vanilla Functions. Specifically, settlement operations (dead-lettering, deferring, etc) and transactional processing (aka send-via).

[fabiocav]

Yes! Absolutely. There are some plans, but it would be great to have a discussion on this. For some SDKs/Services, this will be relatively straight forward, but for services like SB, there are some interesting challenges to tackle.

[Prinsn]

@fabiocav What about a migration strategy away from service bus to something else?

There really needs to be a harm mitigation strategy if there isn't going to be an MVP for a simple migration to 5.0. The suggestion that we would need to wait till 6.0 to upgrade to 5.0 is concerning from a feature adoption standpoint.

[SeanFeldman]

@Prinsn this is relevant to all SDK types, not just ASB. And what will you migrate to? Also, not to be rude, how do you see this logistically working out? The team that is working on multitude of issues to provide support for SDK types and providing a migration implementation?

Allow me to ask, what's the harm in holding off from migration for a bit? The older SDK is not gone and will be supported for a while. Let the SDK types support shape up, see if that works or not, and then upgrade/migrate.

[Prinsn]

This was last but I'm elevating it because it seems to be meaningful: Apologies as my specific problem may have been made too generic by posting in this context, I was scraping for any semblance of an answer to these issues and this was just one of the places I ended up. I don't think it strictly applies to SDK type support, but it still results in collateral damage to my project and team. I understand, however, that this is a catch 22, because no support is worse than partial support, but the breaking changes for the Functions do not list anything of the sort, which means that, in combing for some solution out of our current problem, I'm left to assume that it is a fault of the teams managing the project to not recognize "unsupported features" as non-breaking changes, and to not have any suggestion as to how one might work around the breaking change, as we are experimenting with. How is it not a problem to have to block 5.0 till 6.0? We're what, 7 months out from 5.0, and if we rely on things that require us to move to 5.0, we're basically deadlocked on the fact we're using this software, without a migration strategy, unless we can figure out how to mitigate the situation. I don't think it's rude to ask, it's a completely legitimate course of asking, but .NET Core 4.0 was skipped because 5.0 was going to just be the... reconsolidation of things into one release version? And then having to wait to 6.0, it's very frictionfull. (I respect that the things being done now are to mitigate that, but 5.0 support cannot wait till 6.0, by definition). The specific more narrow case is that our internal security features updated to 5.0, and no projects not using ServiceQueueBuses and MessageReceivers seem to have been impacted, so we would have to fall out of our internal specifications to utilize this project. Granted, there are ways to work around this, but none of them are great to do. By having no stopgap MVP, it puts us in a difficult position, and there are multiple cascading dependencies on 5.0 that we have in Angular that actually prevent us from upgrading from Angular 7 without having them. However, our team was able to figure out a migration strategy, pending testing, since this was posted. Presuming that it passes muster, it seems like it would have been prudent to document such a thing for people coming into the space to apply, and it's something that seems relatively straightforward (perhaps to the point of a literal "duh"): Utilizing the Azure APIs directly instead of relying on the SDK provided types to do it. It's entirely possible myself and all the SO posts and other issues related that I've found have all lost the plot, but it does seem to hold that the SDK fully supporting 5.0 is an MVP requirement by definition (that is to say, having no replacement for legacy code, this is a weird statement, and I think I phrased it poorly), so not having a simple reference as to how we're just boned by circumstance feels lacking.

[jmblanco93]

Is there any news regarding this issue? (Using ServiceBusReceiver class to send a message to the DLQ)

[Prinsn]

I'm also interested if this is "fixed fine" in .NET 6 with respect to that the new version in 5 is delayed to 7.

…

On Wed, Nov 10, 2021 at 4:06 PM Jose Blanco ***@***.***> wrote: Is there any news regarding this issue? (Using ServiceBusReceiver class to send a message to the DLQ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#226 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYR7G5AERSZFF6FL74HMBLULLNE3ANCNFSM4YTZ62IA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Jeff Miller

[isakengstrom]

Any updates to this for .Net 6 isolated workers for Azure function Service Bus triggers? Using Azure.Messaging.ServiceBus version 7.5.1

According to this documentation for Service Bus triggers, it should be possible to use the ServiceBusReceivedMessage binding instead of string, but can't seem to make it work.

[Prinsn]

I have no information on isolated, but aside from migration and upgrade growing pains, the 'default' non isolated seem to be working

…

On Wed, Feb 2, 2022, 6:26 AM Isak Engström ***@***.***> wrote: Any updates to this for .Net 6 isolated workers? — Reply to this email directly, view it on GitHub <#226 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYR7G44YFXOPQ3PTTVZB5TUZEIGJANCNFSM4YTZ62IA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[zaha]

According to this documentation for Service Bus triggers, it should be possible to use the ServiceBusReceivedMessage binding instead of string, but can't seem to make it work.

Yeah, same here, doesn't work for me either. I also need the option to work with a receiver and sender to do some custom retry handling with an exponential backoff timer, which is sadly not possible right now without these SDK types being supported by the isolated-process bindings.

Hope this will come soon 🤞

[SeanFeldman]

The roadmap for Azure Functions had the following for .NET 7 and beyond:

Long term, our vision is to have full feature parity out of process, bringing many of the features that are currently exclusive to the in-process model to the isolated model. We plan to begin delivering improvements to the isolated model after the .NET 6 general availability release.

Are there any discussions taking place to address the gap in the Azure Service Bus trigger? It's only growing, making Isolated Worker SDK only usable for read-only operations with auto-completion but not any other scenario where other message settlement operations need to occur. And with .NET 7 approaching quickly and the convergence of the two Functions SDKs into one, Isolated Worker is concerning, especially for solutions in production using In-Proc SDK that cannot be migrated to the new SDK due to the gap.

/cc @fabiocav

[isakengstrom]

Reply to @SeanFeldman

Are there any discussions taking place to address the gap in the Azure Service Bus trigger? It's only growing, making Isolated Worker SDK only usable for read-only operations with auto-completion but not any other scenario where other message settlement operations need to occur. And with .NET 7 approaching quickly and the convergence of the two Functions SDKs into one, Isolated Worker is concerning, especially for solutions in production using In-Proc SDK that cannot be migrated to the new SDK due to the gap.

Found this recent update on youtube, from the MS team. Summary: The team is actively investing into closing the gaps.

[SeanFeldman]

Any updates that could be shared, @fabiocav?

[schneidenbach]

@fabiocav any updates?

[SeanFeldman]

@fabiocav, it doesn't look like this issue is being worked on. The #1008 epic is supposed to bring In-Process features and behaviours to the Isolated SDK. Is that intentional? Is work happening elsewhere and just not tracked/linked correctly? Thank you.

[schneidenbach]

@fabiocav, echoing @SeanFeldman's question here.

[dlstaylor]

Booo Azure Isolated functions! I'm halfway through a rewrite from in-process to isolated to unblock function compatability with EF core 7 and suprise suprise, another microsoft dead-end.

[fabiocav]

Apologies for the delayed response here. The details about the work on Service Bus have been captured in other issues, but this one wasn't appropriately tracked and fell off my radar.

This work is indeed in progress as part of the SDK Type bindings effort. Issue (epic) #1081 tracks the work in Core (including host work) and the various extensions, with Service Bus included.

The initial updates for service bus have been released in preview and are described in the following issues:

• [SDK-Bindings - ServiceBus] Implement deferred binding support in WebJobs Extension #1536
• [SDK-Bindings - ServiceBus] Implement ServiceBus converter to bind to SBReceivedMessage  #1535

While the above does enhance the experience and provides support for some of the simpler SDK types, they don't provide support for message actions yet (any APIs that would require communication with the service).

The following issues track that work and are coming in the next updates. As they also have a dependency on host enhancements being released:

• Enhance Service Bus binding to enable calling service APIs #1538
• Implement ServiceBus extension E2E tests #1561
• Update ServiceBus dotnet-isolated templates and docs for message settlement #1799

I hope this update helps. We're making good progress towards parity with the in-proc experience here. Thank you all for the patience.

[mattchenderson]

Hi all - we are getting ready to cut a GA version of the package (5.12.0) as-is with ServiceBusReceivedMessage support only. We're basically splitting the work scopes, and you can expect a new preview that will add message settlement to come later. But we are at a point where we feel confident in the behavior for the existing scope, and we didn't want to keep folks from using that while we continue working on the next stage.

To provide a progress update on that next stage, as Fabio mentioned above, there is a dependency on host enhancements that are now code complete and will be rolling out in the next host version. There's also work actively underway to consume that from the Service Bus extensions, and once all of that is complete, we'll be able to line up that new preview release.

[mattchenderson]

Hi all - I'm very pleased to report that version 5.14.0 is now available with message settlement!

You can add a ServiceBusMessageActions to your function signature when binding to ServiceBusReceivedMessage. From there, you can use the methods it exposes to perform settlement operations with the ServiceBusReceivedMessage.

[Function(nameof(ServiceBusReceivedMessageFunction))]
public async Task ServiceBusMessageActionsFunction(
    [ServiceBusTrigger("queue", Connection = "ServiceBusConnection")]
    ServiceBusReceivedMessage message,
    ServiceBusMessageActions messageActions)
{
    _logger.LogInformation("Message ID: {id}", message.MessageId);
    _logger.LogInformation("Message Body: {body}", message.Body);
    _logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);

    // Complete the message
    await messageActions.CompleteMessageAsync(message);
}

Docs are not yet updated at time of posting this comment. Those should be lighting up within the next 24 hours.

We are keeping this issue open for now to allow any feedback to roll in. That said, if you encounter any problems with the new support, please file a new issue so we can track those granularly, but include a link to this one in the description so they get associated.

[Nehmiabm]

 ServiceBusMessageActions messageActions

Thank you for the wonderful news! I'm sorry if this comes out as a dumb question but wanted to ask if we can inject 'ServiceBusMessageActions' in Function Middlewares? Or is it only available in a Function signature?

[SeanFeldman]

@Nehmiabm, not a dumb question at all.
Having access to the incoming message and message actions in the middleware is paramount if you build anything that is a framework like on top of isolated worker functions SDK. See #1824

[Nehmiabm]

Thank you @SeanFeldman for pointing me to the answer to one of my other question I had in mind. I'm looking to implement a Recoverability Middleware that provides configurable retries and I was wanting to access the message actions so that I can schedule, defer or complete the incoming message after exception. Wondering if it Could be accessed from the Function Context similar to ServiceBusReceivedMessage.

[SeanFeldman]

As of today, it seems to be possible only when a message is fully materialized in the function and exception is thrown. The issue I linked to is a better place to discuss it.

[mattchenderson]

Closing as completed. We'll continue to follow up on any referenced issues.