For the

Flow

state lifecycle, is there any specific reason the

Client.set_flow_run_state(flow_run_id, state)

call doesn’t return the new state? Or is it just that, unlike the task version, the flow state lifecycle is much more streamlined and it just hasn’t been needed up until now?

I think that’s exactly it - was only required for tasks up til now

Gotcha! Okay, was realizing the PR for flow concurrency limiting would probably require flows to be able to be set to

Queued

as a state, so wanted to make sure I understood why it was the way it was before starting to hit it with a wrench 🙂

:yes: