Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

During workflow/actor registration, validate metadata endpoint reflects actor-compatible state store #1369

Open
WhitWaldo opened this issue Oct 17, 2024 · 1 comment
Milestone

Comments

@WhitWaldo
Copy link
Contributor

Describe the feature

A recurring concern was raised in Discord and then in dapr/dapr#8208 indicating that it was unclear why the app would fail to start up during workflow initialization and this was later traced to there not being an actorStateStore registered to use.

While this makes for a prime documentation target to clarify, the SDK could do more on this front as well.

The specific details need more consideration, but I'm initially thinking that because of the hot reload capability for components, this should be implemented as a sort of health check (read: recurring) registered whenever the developer registers the Dapr actor runtime or the Dapr workflow client. As @olitomlinson mentioned, rather than necessarily expand on the Health API here, this could simply retrieve the configuration from the Metadata endpoint and indicate whether an actor-compatible state store is registered, then fail in the application with a clear exception.

Release Note

RELEASE NOTE: ADD Validate whether actor state store is correctly registered during SDK initialization preempting endless connection failures

@WhitWaldo WhitWaldo added this to the v1.15 milestone Oct 17, 2024
@WhitWaldo WhitWaldo assigned WhitWaldo and unassigned WhitWaldo Oct 17, 2024
@olitomlinson
Copy link

I think using the metadata endpoint for an initial check is fine, as this is going to cover most common use-cases.

I also think that if a mismatch is detected, then the SDK should throw an Exception, rather than just log an error/warning.

The solution can eventually be upgraded to support post-initialisation changes i.e. with hot-reload support, but I see this as a should, not a must at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants