Fix Dapr apphost startup failure with undefined parameters #959
Conversation
|
Video for reference: Screen.Recording.2025-11-11.at.12.37.52.AM.mov |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a critical issue where Dapr apphosts would crash during startup when parameters were defined without explicit values. The fix defers the resolution of secret values from the OnBeforeStartAsync event to the EnvironmentCallbackAnnotation execution, allowing users to set parameter values via the dashboard before components attempt to use them.
Key changes:
- Deferred secret value resolution to align with parameter availability timing
- Changed storage from resolved values to value providers for lazy evaluation
|
@gabynevada would it be possible to have test coverage for this, or is it too internal? |
Fix startup failures when Dapr components reference parameters or value providers that don't have values at initialization time (e.g., user-provided secrets via dashboard). Previously, secret parameters were resolved immediately during the lifecycle hook execution, causing failures when parameter values weren't available yet. Now, value providers are stored and resolved later during environment setup when all parameter values are available. Changes: - Store secret value providers instead of resolving them immediately - Defer resolution to EnvironmentCallbackAnnotation execution - Add tests verifying parameters are stored as IValueProvider instances 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
gabynevada
force-pushed
the
fix/dapr-parameter-deferred-resolution
branch
from
b5d7e51 to
d1c5df3
Compare
|
@aaronpowell added some annotation unit tests for it. Don't really know how to perform integration tests for this behavior. |
This is Copilot town, geddout! 🤣 |
|
Maybe I should give copilot a chance again 😂 |
2 participants
Summary
Fixes #958
This PR resolves an issue where the Dapr apphost would fail to start when parameters were defined without explicit values. The fix defers the resolution of secret value providers (including parameters) until the environment callback is executed, allowing users to set parameter values via the dashboard before Dapr components attempt to use them.
Problem
Previously, when you defined a parameter without an explicit value (intending to set it later via the dashboard), the apphost would crash during startup. This happened because secrets and parameter values were being resolved during the
OnBeforeStartAsyncevent, which occurs at startup before users have a chance to provide values through the dashboard.Solution
The fix changes when secret values are resolved:
OnBeforeStartAsync(line 105 in old code)IValueProviderinstances and resolved later during theEnvironmentCallbackAnnotationexecutionThis ensures that parameter values can be set by the user before Dapr components try to access them.
Changes
Dictionary<string, string>toDictionary<string, IValueProvider>for secretsTests
Added comprehensive test coverage to verify the deferred resolution behavior:
SecretParameterValueStoredAsProviderNotResolvedValue- Verifies that when a secret parameter is defined without an explicit value (simulating user input via dashboard), it's stored as anIValueProviderrather than being resolved immediately. This test ensures the root cause of the bug is fixed.ValueProviderStoredInComponentAnnotation- Verifies that value providers (like endpoint references) are stored in component annotations and not resolved prematurely. This validates the broader pattern works for all types of value providers, not just secrets.Both tests assert that the values remain as
IValueProviderinstances in the annotations, proving that resolution is deferred until the appropriate time when all values are available.