Dapr Actor Example?

[pjmagee]

I can't get a simple actor setup working but looking through some of the Dapr configuration DaprClient is not setup the same way as the ActorProxy class. Wondering if it should be working and I'm just not sure how to set it up correctly with an asp.net core web project hosting the actor proxy implementation and getting a simple console app to use the Proxy and make calls to the actors. The connection doesnt seem to work for me, but there's no starter sample using actors so I'm not sure if its me or if it's been an oversight with Actors being different to Sidecar web services or something?

[davidfowl]

cc @philliphoff

[philliphoff]

I'm seeing an issue with Dapr actors and Aspire as well (on Preview 2). If running via Aspire, the Dapr sidecar doesn't appear to fetch the application's configuration (which contains, among other things, its registered actor types). However, my own requests to the application's /dapr/config endpoint return the expected registrations. If I take the same command line for the Dapr sidecar (as shown in the Aspire dashboard), the sidecar does appear to fetch the application's configuration and notice its registrations.

@karolz-ms Are there any implicit proxies between the Dapr sidecar and the application in the normal single-replica case?

[karolz-ms]

Yes, the sidecar and the replica are both currently modeled as services, so each gets its own proxy. Is the sidecar a singleton, regardless how many replicas it serves? If so, it would be a candidate to switch to "proxyless service" mode, which DCP does support since preview 2.

[philliphoff]

The Dapr sidecar has a 1:1 relationship with the service. There should be a separate sidecar instance for each service replica, though the sidecars will share the same application ID; the sidecars will use their own scheme for distributing traffic across replicas. (I don't know if Aspire is creating multiple sidecars today; I haven't done any testing to date with replicas.)

[mitchdenny]

Tagging with area-app-model-offsite because I think this is a hard problem to solve in our current architecture. Standing up replicas is controlled by DCP, but by the time they start getting spun up it is too late to start adding in extra containers/executables.

[davidfowl]

Did we fix this @karolz-ms ?

[philliphoff]

@davidfowl Using the 8.0.0-preview.3.24072.3 daily build of Aspire, I'm no longer seeing this issue. The service actors are getting registered and I can invoke them from a client application.

@pjmagee You might try with a recent daily build or wait until the upcoming Preview 3 to see if your issue is, indeed, resolved.

[laurentkempe]

(I don't know if Aspire is creating multiple sidecars today; I haven't done any testing to date with replicas.)

@philliphoff I just tried this tonight and it doesn't create multiple sidecars ☹️

[davidfowl]

preview3?

[laurentkempe]

I think it was preview 4

[davidfowl]

@philliphoff can you add an actor example to the dapr playground project?

[danmoseley]

@philliphoff is this something you plan to do? we moved out of GA anyway.

[msislam3]

This is happening for me still. We are using dapr actors in multiple production deployed projects and would love to integrate Aspire for local development. If I use VS Code to run the project (based on official documentation) the system works fine but if I run using Aspire, the Actor Proxy is not able to call any actor methods.

This the log from the dapr sidecar

2024-10-04T13:13:16.2720000 time="2024-10-04T09:13:16.2723811-04:00" level=debug msg="api error: code = Internal desc = error invoke actor method: did not find address for actor JobContextDataPollActor/qa1_19986" app_id=system-monitoring-service instance=5CG3290HV0 scope=dapr.runtime.http type=log ver=1.14.2 2024-10-04T13:13:16.7260000 time="2024-10-04T09:13:16.7266552-04:00" level=warning msg="Error processing operation DaprBuiltInActorNotFoundRetries. Retrying in 1s…" app_id=system-monitoring-service instance=5CG3290HV0 scope=dapr.runtime type=log ver=1.14.2 2024-10-04T13:13:16.7260000 time="2024-10-04T09:13:16.7266552-04:00" level=debug msg="Error for operation DaprBuiltInActorNotFoundRetries was: did not find address for actor JobStateActor/qa1_19934" app_id=system-monitoring-service instance=5CG3290HV0 scope=dapr.runtime type=log ver=1.14.2

It would be helpful to have a Dapr + Aspire sample that uses Actors

[philliphoff]

@msislam3 I have a quickly-thrown-together sample here: https://github.com/philliphoff/DaprAndAspireSample

[msislam3]

@philliphoff I think I have found the issue. The repo really helped. I was calling WebApplication.UseHttpsRedirection() extension method in the actor project. The actor calls started to work when I removed it. I don't need this call so it worked for me but I am not sure why this call would cause the issue and why it works in VS Code setup.

[msislam3]

@philliphoff I have reproduce the issue with your repo by adding the same extension call I am not sure if I should create a new issue or it's normal

[philliphoff]

@msislam3 My guess is that the Dapr sidecar may not be following the redirect to the HTTPS endpoint when it's attempting to invoke/manage the actors in the service (as, by default, the Dapr sidecar uses HTTP). My interpretation of the ASP.NET guidelines is that web APIs (like an actors project) shouldn't redirect to HTTPS (as it risks clients still calling the HTTP endpoint with sensitive data--instead they should only expose an HTTPS endpoint). In that case, you could configure the Dapr sidecar explicitly use the HTTPS endpoint.

[msislam3]

@philliphoff no it makes sense. I agree that an web API should not expose http endpoints. In fact our project is not. I am not sure why we had that redirect call. I have removed it and it's working. Thanks for your help on this!