Change Grpc port

[RichardBurns1982]

When running locally we have multiple functions running and we are using the extension AddDurableTaskClient so we can inject this to start orchestration functions:

services.AddDurableTaskClient(b =>
        {
            b.UseGrpc(grpcConfigure =>
            {
                grpcConfigure.Channel = GrpcChannel.ForAddress($"http://localhost:{PORT}");
            });
        });

How do we change the port so that one function can run GRPC on a different port to another function? When we try overriding the port we get connection errors from the GRPC framework.

This only affects us locally when developing as we can't have more than one function running at the same time but we would like to work around that limitation.

[jviau]

@RichardBurns1982 - are you using durable task standalone, or durable functions?

There has to be something on the other end of that port listening to this gRPC connection. In Durable Functions, you don't add the client yourself. Instead, you use the [DurableClient] DurableTaskClient client input binding to your function - the framework will handle providing a client which talks back to the functions host.

In DurableTask standalone, you need to know what port your gRPC sidecar is running on - but we haven't really made the sidecar support official yet. That is still to come.

[RichardBurns1982]

@jviau Thanks for the response.

We are using durable functions.

We have multiple function projects, for example:

Function1
Function2
Function3

Each of these we are calling:

services.AddDurableTaskClient(b =>
        {
            b.UseGrpc();
        });

This allows us to take a dependency on DurableTaskClient in our classes from the DI container and this all works really well allowing us to start Orchestration Functions. As we are not changing any of the GRPC settings it is defaulting to port 4001. This is all fine if we are running a single function project locally or when deployed to Azure.

However, we have a need when developing locally to run multiple function projects at the same time, all of these are by default listening on port 4001. What we want to do is change it, when the HostingContext.IsDevelopment() is true and have:

Function1 - Port: 4001
Function2 - Port: 4002
Function3 - Port: 4003

Is this possible? The reason being we have an integration event framework which has subscriptions in each function project which triggers different orchestration functions in each project. The integration event handlers are resolved from the DI container with DurableTaskClient as a dependency.

[jviau]

DurableTaskClient is not meant to be used that way in Durable Functions. The port is supplied from the host extension as part of the input binding process, it is not known at startup.

See documentation here for examples on how to use the [DurableClient] input binding.

[RichardBurns1982]

Thanks again for the response. Is there no way to take DurableTaskClient from the ServiceCollection? Without having to take in the function method using input binding and pass down through methods to our service classes? We used to do this in .net6 in-process. Technically this is working fine now except locally when we have multiple functions running locally and they're all trying to run on port 4001. We've not observed any issues in production, what issues would you expect us to be seeing? I could provide a sample solution if easier so you can see how we are using this and what alternatives you'd suggest. Many thanks again, I appreciate the help/responses. Additional: Even when injected with Input Binding the rpcBaseUrl":"http://localhost:4001", how would we run two functions locally at the same time if they are both running on port 4001? Additional 2: Thanks @jviau for your help, I have changed to use InputBindings and passing that down and it is working running multiple functions locally. Is there any plan to allow DurableTaskClient to be resolved from the DI container in Durable Functions?

[jviau]

For durable functions in dotnet isolated, no there is no way to do this. You simply do not know what the gRPC port to bind to is, it is only supplied to the worker as part of input binding via the [DurableClient] attribute. This isn't to say we won't support to eventually; it totally depends on how/if things change in the functions extensibility model. In-process is different, there is no concept of talking from worker to host there, you are just accessing the backing durable task services directly - so they can be resolved via DI.

When you say "two functions locally", are you talking about two separate function apps entirely, or just two functions within the same project?

[jviau]

We've not observed any issues in production, what issues would you expect us to be seeing?

Want to clarify this. The functions extension code will first attempt to bind to 4001, so it may work for you most of the time. But when that port is reserved it will start trying to get random ports in the 30000 to 31000 range. This is when you will fail to bind to that client.

I understand your desire though, it would be nice to have the client in the DI container. I am currently exploring a feature which may enable this, I'll update this if that happens.

[jviau]

Closing this in favor of #154 - which will solve this issue.

[BYM-Henry]

@RichardBurns1982 did you ever find a workaround for this? We are currently experiencing the exact same issue, with getting an error when trying to run two function apps locally both injecting a DurableTaskClient into a service.