SeanFeldman
commented
1 year ago Following .NET 7 release, which included removal of support for in-process function execution model, I'd like to share how I tried to adhere to the isolated worker approach for my custom trigger, and issues we are facing.
Unfortunately, that post hasn't aged well. There was an update, which should have been more prominent and amplified, which stated:
The previous post implied a specific timeline for phasing out the in-process model, with .NET 8 only supported on the isolated process model, which is possible but not guaranteed. That change would only occur if the isolated process has reached sufficient parity with the in-process model as outlined in this post. If it does not, there would be an in-process version of .NET 8 support.
With .NET 7 out, rephrased version would be "In-Process is not dead and continues till .NET 8 or feature parity, whichever comes first".
Greybird
lgmorand
mattchenderson
liliankasem
Hi,
Following .NET 7 release, which included removal of support for in-process function execution model, I'd like to share how I tried to adhere to the isolated worker approach for my custom trigger, and issues we are facing.
I'm doing it in Issues as Dicussions space is not open.
Context
MassTransit
In my company, we are heavy users of the MassTransit (doc site) library. We have plenty of procedures and ways of doing that are linked to how MassTransit is behaving.
One of them is the automatic topics, subscriptions, and queues creation at runtime, from message types, based on conventions (yes, it required credentials allowed to do so). Others include
_errors(something went bad during message consumption) and_skipped(no consumer for the message type was configured) queues.Custom trigger
We previously used WebJobs a lot to consume messages, but we decided to move to functions.
To that end, we created a custom trigger that would allow us to get all the benefits from MassTransit library with the functions runtime.
You can find a very initial version here, that we published as part of a blob post, which should be simple enough to understand how it works.
If you take a look at the README, you will see that we relied on dependency injection to inject code configuration for the MassTransit library.
The result is quite crude, but works perfectly.
Issues encountered migrating to Isolated Worker
ExtensionInformation relying on nuget
The fact that the
ExtensionInformationAttributeis relying on a nuget package is painful during development, and requires specific setup to be able to debug something. This is not a big issue, but it does not helpAbility to inject into the host
As the plugin relies on code to configure the trigger, we had to find a way to inject code into the host. The best solution we could find was to code an extension, as the extension would be executed in the host. As the configuration code relies on message types, we had to ensure the message types would be in a dedicated project too (not a big issue in our case, it was already the case to distribute them to clients through a specific nuget). Of course, for the trigger users, it would be more painful, as they would have to package a project as an extension, but at least it would work.
We did not find how to inject into the build process to register an extension, but it seems hard to do. So instead, we relied on manual modifications of
extensions.json, and manual copy of files into the.azurefunctions. We had to add a few System.* dll for .NET 7, but this is probably to be expected as we hacked the build process.So possible, but hard to find how to automate the extension registration in a simple way.
Unavailability of the parameter type on the trigger extension.
As said above, MassTransit uses conventions based on message types to configure the infrastructure. Even having the configuration extension running in the host, we discovered that the GRPC protocol did not transfer the attributed parameter type from the worker to the host, presenting it as a simple string, while the trigger expects it to be set to a proper parameter type.
As such, even relying on previous hacks, this made clear we would not be able to implement the customer trigger we wanted.
Conclusion
Could you clarify exactly where you are headed towards feature parity for custom triggers, and maybe a little bit of a timeframe for this parity to occur ?
The removal of the in-process model broke our ability to rely on functions, with little alternatives left currently, in a (probably small with regards to the functions world, but still) range of use cases.
Could we expect being able to inject configuration into the host easily ? And to have access to (nearly) the same information from an isolated worker than from an in-process work.
Thanks for reading !