blocked-duration-in-seconds does not seem to work about dapr HOT 2 CLOSED

cc @JoshVanL

from dapr.

Thinking out loud... Please correct me if I've got any of this fundamentally wrong :)

Given steady state, and App Health probe is failing, then I would expect the following :

• any new inbound requests (Dapr -> App) to be rejected
• any in-flight inbound requests (Dapr -> App) to continue processing.
• Outbound requests (App -> Dapr) should be unaffected by a failing App Health probe and be allowed as normal

Given a SIGTERM on Dapr, and the App Health probe is failing, how long should in-flight inbound requests (Dapr -> App) be allowed to continue before they are terminated?

My initial thought is that in-flight inbound requests should be allowed to continue indefinitely until SIGKILL. Is there any reason to not allow in-flight requests to continue until SIGKILL? I think this is where we believe the bug currently lies as in-flight requests are killed instantly during block-shutdown-duration due to aggressive behaviour here which is terminating in-flight requests, rather than just detaching subscriptions to prevent new requests.

Given SIGTERM on Dapr, and the App Health probe fails but then flips to healthy, and Dapr is in the middle of block-shutdown-duration phase or the graceful-shutdown, should Dapr allow new inbound requests once again?

My guess here is No, as the SIGTERM is a clear indication that the containers are going away, so why start allowing new inbound work...?

from dapr.