ERR_ACTOR_RUNTIME_NOT_FOUND

[jefersonmanjos]

When I try to run actor I received the flow message even with statestore configured with actorStateStore value true.

{ "errorCode": "ERR_ACTOR_RUNTIME_NOT_FOUND", "message": "the state store is not configured to use the actor runtime. Have you set the - name: actorStateStore value: \"true\" in your state store component file?" }

So I have this component:

apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: statestore spec: type: state.redis version: v1 metadata:

• name: redisHost value: localhost:6379
• name: redisPassword value: ""
• name: actorStateStore value: "true"

I'm missing any configuration?

[hanxinimm]

me too.

[billy723]

I also encountered the same problem when trying the actor example on the official website of dapr.

[ghost]

I'm also running into this issue. I also tried everything as exactly done within the https://github.com/dotnet-architecture/eShopOnDapr/blob/main/docker-compose.override.yml file from the official sample project. It seems like the redis store actually is connected and the component was found within the specified volume.

[scosta-kar]

Ran into that same issue setting up a poc project. On my end problem was the port you specify when running dapr needs to match the port asp is running on: dapr run --app-id myapp --app-port 5028 --dapr-http-port 3500 -- dotnet run --urls "http://*:5028"

[halspang]

Yes, you need to specify the app port for it to initialize the actor runtime. If you don't you'll get this error.

This error isn't clear for what's actually happening though. It'd be worth looking into why this specific error is raised and if we can change it to something more appropriate.

[billy723]

I also encountered the same problem when trying the actor example on the official website of dapr.

I have found the problem. In order to avoid this problem and other situations, please confirm the following:

（1）Asp.NET startup port number configured by the web application is consistent with the port number of the hosting service enabled by the dapr command

(2) The specified actor name is consistent with the created actor class name,otherwise, the error "please confirm the status store as true" will be caused

[hanxinimm]

@halspang

app port is required？my app just a client to call actor service.

how long time to fix it? it break my production environment

[maxpu80]

Hi! The problem is reproduced for me also

Env:

Windows 10 dapr -v CLI version: 1.8.0 Runtime version: 1.8.4 docker -v Docker version 20.10.14, build a224086

The application works fine when started with dapr cli and fails with the error when started with docker-compose None of the suggestions from above works for me

I've created repo with details in readme where you can reproduce error easily https://github.com/maxpu80/eth-scrapper/tree/fix/docker-compose-fails

Any help appreciated, Thanks !

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[jackbond]

This should not be marked as stale. I've been losing my mind for the last five days trying to get an actor to work using docker-compose. I finally stumbled upon this issue.

@maxpu80 Did you ever have any success? I've tested with the lastest Docker and Dapr NuGets with no success.

[jackbond]

I've dug into this issue deeper. The error message "the state store is not configured to use the actor runtime" is clearly a red herring. As others have commented, you need to be sure you've got the --app-port correct, and what this hints at, is that if the sidecar isn't able to communicate with its related service, it gives the really poor state store error. In my case I've got serviceA attempting to communicate with an actor service (serviceB). When I attempt to use the actor proxy in serviceA, I get the state store error, so I tried making some basic http calls (via HttpClient) just prior to using the proxy, and I got some interesting results.

Calling http://serviceB:5402, I get a successful response Calling http://localhost:3500/v1.0/actors/MyActorName/ARandomId/reminders/rk, the response contains the state store error Calling http://localhost:5402 I get "Cannot assign requested address" Calling http://127.0.0.1 I get Connection refused

The last one is somewhat interesting, if I retrieve http://127.0.0.1 in a browser, I get a successful response. Without digging into the dapr code, it seems like the sidecar, when launched via VisualStudio / docker-compose.yml, is attempting to communicate with its associated service using http://localhost or http://127.0.0.1, instead of http://app-Id:app-Port.

A couple extra notes for clarity.

I see the following during startup, so I'm pretty sure the statestore is being properly configured. time="2022-11-13T19:18:56.1030189Z" level=info msg="component loaded. name: statestore, type: state.in-memory/v1" app_id=myappname instance=aa8cada5224e scope=dapr.runtime type=log ver=1.9.0

I switched to in-memory state store just to reduce one potential source of errors, but see the exact same behavior when using the redis state store.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[jackbond]

I literally gave up on DAPR because I (and clearly others) have identified a bug, and apparently it's nobody's responsibility to fix it. So sure, mark at as stale and move on, I'm sure that will resolve it.

[yaron2]

I literally gave up on DAPR because I (and clearly others) have identified a bug, and apparently it's nobody's responsibility to fix it. So sure, mark at as stale and move on, I'm sure that will resolve it.

I am sorry to see this has been your experience. However, as the correspondence on this issue shows, there isn't actually a bug to fix in terms of actor functionality and once setting up the correct app port, the situation resolves. You are very right that the error message in the case you experienced can be greatly improved. As such, I've edited the title of the issue and added it to our 1.10 milestone.

[halspang]

@jackbond - I took some time to also validate specifically that this all works via docker-compose and have found everything to be functioning.

Another important thing to remember here when running in docker-compose is that you may need to specify the placement server's address and/or start it if you haven't already.

Also, I think you can fix the network issue you stated there by including a line like this for the dapr sidecar (example taken from my test):

network_mode: "service:testbed-actor"

[jackbond]

"I am sorry to see this has been your experience. However, as the correspondence on this issue shows, there isn't actually a bug to fix in terms of actor functionality and once setting up the correct app port, the situation resolves."

I literally fiddled with settings for a week, including tweaks to network_mode and app port.

@maxpu80 provided a full sample where it looks like he's setting the app port.

I appreciate you guys taking the time, but can someone PLEASE provide a working sample of service communicating with an actor running via docker compose, i.e. I can download it, extract it, load it in Visual studio, hit F5? For someone with experience with DAPR it ought to take them less than 10 minutes to create it.

[halspang]

@jackbond - I'll create an example in the dotnet sdk once I get some time. In the meantime, I fiddled with the repo that was linked above and as anticipated it is a problem with the app port. Or, more specifically, that dapr can't reach the app due to how the docker-compose is setup.

I am a complete docker novice, so if this isn't the right practice, I apologize. However, I was able to get their example working by doing what I stated above with network_mode: "service:...". However, do to this, it also removed the ability to talk to Dapr directly. As such, I made a 2nd sidecar (with no app) that acts as a client.

I also put them all into the same network hello-dapr. I don't think that's strictly necessary, it's just what I found in a docker-compose example that didn't use actors.

Here's the yaml as I adjusted it:

version: '3'
services:
  placement:
    image: "daprio/dapr:1.9.5"
    command: ["./placement", "-port", "50006"]
    networks:
      - hello-dapr
  redis:
    image: "redis:alpine"
    ports:
      - "6380:6379"
    networks:
      - hello-dapr
  ############################
  # docker-dispatcher-actor + Dapr sidecar
  ############################
  scrapper-dispatcher-actor:
    build: 
      context: ./dotnet/Eth
      dockerfile: ScrapperDispatcherActor/Dockerfile         
    ports:
      - "3000:3000"
    environment: 
      - PORT=3000
    depends_on:
      - redis
      - placement
    networks:
      - hello-dapr
  scrapper-dispatcher-actor-dapr:
    image: "daprio/daprd:1.9.5"
    command: ["./daprd",
     "-app-id", "scrapper-dispatcher-actor",
     "-app-port", "3000",
     "-dapr-http-port", "3500",
     "-placement-host-address", "placement:50006",
     "-components-path", "/components"]
    volumes:
        - "./docker-compose-components/:/components"
    depends_on:
      - scrapper-dispatcher-actor
    network_mode: "service:scrapper-dispatcher-actor"
    depends_on:
      - scrapper-dispatcher-actor
    # ports:
    #   - "3500:3500"
    # networks:
    #   - hello-dapr
  dapr-client:
    image: "daprio/daprd:1.9.5"
    command: ["./daprd",
     "-app-id", "dapr-client",
     "-dapr-http-port", "3501",
     "-placement-host-address", "placement:50006",
     "-components-path", "/components"]
    volumes:
        - "./docker-compose-components/:/components"
    networks:
      - hello-dapr
    ports:
      - 3501:3501
    depends_on:
      - placement
      - redis
    
networks:
  hello-dapr: