Put parameters into context inside of a flow run
See original GitHub issueWhen 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.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
Assigning a Parameter Context to a Process Group
To assign a Parameter Context to a Process Group, click Configure, either from the Operate Palette or from the Process Group context menu....
Read more >Flows - Prefect 2 - Coordinating the world's dataflows
Parameters : Flows have first-class support for parameterization, making it easy to run the same group of tasks in different use cases by...
Read more >Which Context Do Flows Run In? - Salesforce Help
Flows run in user context or system context. For a flow running in user context, the running user's profile and permission sets determine...
Read more >How Can we run child flow in context of parent flo...
I have a requirement where I need to get email id of user who runs the Parent flow without sending parameters to child...
Read more >Using Parameter Context to Improve the Data Flow | Apache Nifi
Parameters are an great way to make you Apache Nifi dataflow more efficient. Support the channel by Subscribing!PATREON – Would you like to...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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
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