When a flow runner is in a cloud context it makes a call to the client's get_flow_run_info function. That call queries for the parameters, version, and current_state. The parameters however are not used. Inside the flow runner it can take those parameters (from its flow_run_info object that it creates) and set it in the context here -> https://github.com/PrefectHQ/prefect/blob/master/src/prefect/engine/flow_runner.py#L189 if there are no other parameters passed into the runner.
Question for @joshmeek and @jlowin -- is there any situation in which parameters would be provided to the flow run (via the run() method kwarg) as well as needing to be pulled from cloud? Or are they mutually exclusive? If not, what should the prioritization be? Thanks!
Unlike a State update, there is no worry of Flow Run parameters being obsolete (since they can't change), so we can do either. The advantage of handling it inside the get_flow_run_info call is that we already make this call to get the state and we wouldn't have to worry about parsing JSON strings around various deploy agent.
To @cicdw specific point though, I don't think there's a situation we'd do both.
Reason I'm asking is because I can do 1 of 4 things:
I would vote for prioritizing kwarg over DB because kwarg seems more manual to me as opposed to DB being set once and automatically loaded
I vote for #4 as well -- in general I always prefer the "more recently provided" option. For example auth credentials passed immediately > auth credentials in env var > auth credentials in file system. By that logic, parameters passed immediately to the run() function should take precedence over ones that were presumably set a while ago and are being loaded from db
Most helpful comment
I vote for #4 as well -- in general I always prefer the "more recently provided" option. For example auth credentials passed immediately > auth credentials in env var > auth credentials in file system. By that logic, parameters passed immediately to the run() function should take precedence over ones that were presumably set a while ago and are being loaded from db