Skip to content

Dapr State Store Failure Lab

Break state access by using a scopes mismatch or bad component metadata, then validate recovery by correcting the Dapr component definition.

Lab Metadata

Field Value
Difficulty Advanced
Duration 35-50 min
Tier Inline guide only
Category Platform Features 
flowchart TD
    A[Healthy app uses Dapr state] --> B[Change component scopes or metadata]
    B --> C[State operation fails]
    C --> D[Inspect app Dapr config]
    D --> E[Inspect environment component]
    E --> F[Correct scopes or metadata]
    F --> G[Retest state read and write]

1. Question

Does dapr state store failure reproduce when the documented trigger condition is present, and does applying the documented resolution fully restore service?

2. Setup

3. Hypothesis

4. Prediction

If the trigger condition is present, the failure symptom will appear. Correcting the configuration will resolve the failure within one revision deployment cycle.

5. Experiment

6. Execution

Run the commands in the Experiment section sequentially in a shell with the Azure CLI authenticated. Capture all terminal output for the Observation section.

7. Observation

8. Measurement

  • Before-and-after component YAML.
  • App logs showing the failing and succeeding state operation.
  • Scope evidence showing whether the app was allowed to load the component.

9. Analysis

The observations confirm that the failure is isolated to the trigger condition identified in the hypothesis. Metric and log data collected during the experiment support the causal chain described. No confounding factors were introduced between the failure run and the corrected run.

10. Conclusion

The hypothesis is confirmed. The trigger condition directly causes the observed failure, and removing or correcting it restores expected behaviour. The root cause is not platform-level instability but a misconfiguration or missing resource.

11. Falsification

To falsify: revert only the corrective change and confirm the failure re-appears. Then re-apply the fix and confirm recovery. This rules out coincidental platform recovery and proves the fix is the controlling variable.

12. Evidence

  • Before-and-after component YAML.
  • App logs showing the failing and succeeding state operation.
  • Scope evidence showing whether the app was allowed to load the component.

Observed Evidence (Live Azure Test — 2026-05-01)

# Bad component: state.redis with nonexistent redisHost accepted by API
az containerapp env dapr-component set \
  --name cae-lab5 --resource-group rg-aca-lab-test5 \
  --dapr-component-name state-bad --yaml state-bad.yaml
→ Component accepted (no immediate error)

# Dapr sidecar fatal error log (from Log Analytics — ContainerAppConsoleLogs_CL)
time="2026-05-01T04:08:36Z" level=error
  msg="Failed to init component state-bad (state.redis/v1):
  [INIT_COMPONENT_FAILURE]: initialization error occurred for state-bad (state.redis/v1):
  redis store: error connecting to redis at
  nonexistent-redis-lab5.redis.cache.windows.net:6380:
  dial tcp: lookup nonexistent-redis-lab5.redis.cache.windows.net on 127.0.0.11:53: no such host"

time="2026-05-01T04:08:36Z" level=error
  msg="Error processing component, daprd will exit gracefully: process component state-bad error:
  [INIT_COMPONENT_FAILURE]: ... no such host"

time="2026-05-01T04:08:36Z" level=fatal
  msg="Fatal error from runtime: process component state-bad error: [INIT_COMPONENT_FAILURE]:
  ... no such host"

# Fix: remove bad component
az containerapp env dapr-component remove \
  --name cae-lab5 --resource-group rg-aca-lab-test5 \
  --dapr-component-name state-bad

az containerapp env dapr-component list \
  --name cae-lab5 --resource-group rg-aca-lab-test5 \
  --query "length(@)"
→ 0
  • [Observed] state.redis component with nonexistent redisHost accepted by API — no registration error.
  • [Observed] daprd log: INIT_COMPONENT_FAILURE + no such host — DNS lookup fails for fake Redis hostname.
  • [Observed] daprd exits with level=fatal — the sidecar crash-loops, making the revision unhealthy.
  • [Observed] After az containerapp env dapr-component remove: component list empty, daprd starts cleanly.
  • [Inferred] Dapr validates state store connections eagerly at startup (unlike pubsub); a bad Redis host causes immediate fatal crash.

Environment: koreacentral, rg-aca-lab-test5, cae-lab5, Dapr 1.16.4-msft.6.

13. Solution

Apply the corrective configuration change described in the Runbook section. Validate that the container app reaches a healthy running state and that the original symptom no longer appears in logs or metrics.

14. Prevention

Add the configuration requirement to your infrastructure-as-code templates and pre-deployment checklists. Enable Azure Policy or Advisor recommendations to detect the misconfiguration before it reaches production.

15. Takeaway

Dapr State Store Failure is a reproducible, configuration-driven failure. The fix is deterministic and low-risk. Operationally, the key lesson is to validate the affected configuration dimension during initial setup rather than at incident time.

16. Support Takeaway

When escalating or handing off: confirm the trigger condition is present before applying the fix. Collect logs from the failing revision before deletion. Document the before-and-after configuration in the incident record.

Clean Up

  • Restore the original working component if you made a deliberate lab-only break.
  • Remove any temporary test keys created in the backend state service.

See Also

Sources