codecov[bot]
commented
7 months ago Codecov Report
Attention: 16 lines in your changes are missing coverage. Please review.
Comparison is base (
fc0e9d1) 86.37% compared to head (e656227) 86.18%. Report is 7 commits behind head on main.
| Files | Patch % | Lines |
|---|---|---|
| dapr/clients/health.py | 72.72% | 9 Missing :warning: |
| dapr/aio/clients/grpc/client.py | 92.15% | 4 Missing :warning: |
| dapr/actor/client/proxy.py | 57.14% | 3 Missing :warning: |
Additional details and impacted files
```diff @@ Coverage Diff @@ ## main #674 +/- ## ========================================== - Coverage 86.37% 86.18% -0.19% ========================================== Files 79 82 +3 Lines 4094 4170 +76 ========================================== + Hits 3536 3594 +58 - Misses 558 576 +18 ```:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Description
While validating the 1.13 rc1 I ran into the following 3 issues:
./validate.sh invoke-custom-data(❌ failed to stop app id invoke-caller: couldn't find app id invoke-caller)./validate.sh w3c-tracing(❌ failed to stop app id invoke-caller: couldn't find app id invoke-caller)./validate.sh demo_workflow(❌ details = "error starting workflow 'hello_world_wf': unable to start workflow: failed to start orchestration: error from internal actor: an active workflow with ID 'exampleInstanceID' already exists" == APP == debug_error_string = "UNKNOWN:Error received from peer ipv4:127.0.0.1:50001 {created_time:"2024-02-14T14:14:09.774273+00:00", grpc_status:13, grpc_message:"error starting workflow \'hello_world_wf\': unable to start workflow: failed to start orchestration: error from internal actor: an active workflow with ID \'exampleInstanceID\' already exists"}")This PR addresses the first two issues. The reason for this is a change of behaviour in Dapr, which now properly catches
SIGTERMsignals. The examples usedapr runto run the apps and the dapr cli sends aSIGTERMwhen an application finishes execution. That's why the tests broke now. This behaviour is only evident for short-running scripts.I updated the examples to not try to stop the dapr instance explicitly.
Checklist