Josh van Leeuwen

Because it is a true race condition of LOC and execution, I'm not sure of a way to write a sensible unit test for it.

I can look into doing that. This bug is currently being manifested in Dapr integration tests failing.

Here is an example of a dapr/dapr int test surfacing a variation of this bug ` fatal error: sync: RUnlock of unlocked RWMutex`. https://github.com/dapr/dapr/actions/runs/10780003020/job/29895148587?pr=8066

Hi @artyom-p, indeed this field is required because setting `mtls` to `false`, still means that the dapr control plane will control to use `mtls` with each other, as well as...

Thanks from me as well @AdamKorcz :smile: I'm also been doing some fuzz testing with our integration tests [here](https://github.com/dapr/dapr/pull/6573). I think it's definitely a good idea for us to have...

> I have not used gofuzz extensively. When I tried it (a couple of years ago) I found it to be ineffective. Thanks, I am very interested to know what...

You must either set `dapr.io/config: ""` to a Configuration resource which exists, or not set it at all. Empty string is not valid.

Thanks for the great write up! Regarding your second point- is the app returning the result of the message processing back to daprd, but that result isn’t getting propagated back...

@salaboy we need to update the RBAC permissions as well- we currently can get secrets in all namespaces, as well as read/write ConfigMaps in all namespaces.

@salaboy dapr shared shouldn't need any ClusterRoles at all.