search

man-group / dapr-sidekick-dotnet

Dapr Sidekick for .NET - a lightweight lifetime management component for Dapr
Apache License 2.0
180 stars 21 forks source link

DaprWorkflowClient doesn't use specified ports #66

Open sclarke81 opened 1 month ago

sclarke81 commented 1 month ago

Expected Behavior

To be able to use the DaprWorkflowClient with DaprSidekick.

Actual Behavior

The DaprWorkflowClient is created during initialisation (unlike the DaprClient which is created on first use). This means that it looks for the DAPR_GRPC_PORT and DAPR_HTTP_PORT environment variables. These env vars haven't been set yet though because they're only set when sidekick starts the sidecar. Perhaps the env vars could be set earlier?

Steps to Reproduce the Problem

Use Dapr Workflows and Sidekick with a non-default HTTP and GRPC sidecar port numbers.

Release Note

RELEASE NOTE:

badgeratu commented 1 month ago

Hi, appreciate this is an issue. Have started looking at it now. I agree first step is to at the very least respect the DAPR_GRPC_PORT and DAPR_HTTP_PORT environment variables as a pass-through if set externally before startup - that will ensure Sidekick and the Workflow client use the same values. I've brought in the .NET SDK WorkflowConsoleApp sample which is a pretty good starting point and made some changes to make that work properly, which hopefully is a step in the right direction.

I'll have a think next about how we can maybe do something better in the bootstrap/startup of Sidekick. It's a bit challenging when it's all in the same IServiceCollection container to constrain an order on things but maybe there's something we can do.

I've also read through the #workflow thread on Discord and seen the challenges you've been facing. Just want to say thank you so much for persevering with Sidekick!