Amanda Wee
01/16/2021, 11:56 AMidempotency_key
matches the one from the previous flow registration, the flow version is not bumped. However, does the serialised flow get uploaded to storage anyway? I'm too newbie at the codebase (and graphql in particular) to make sense of the details of the flow registration code.If you are registering flows using automation, you may want to pass an idempotency_key which will only create a new version when the key changes.
but if the serialised flow is saved in storage anyway, then automation that keeps re-registering the flow will eventually fill up storage with junk. After all, the flow version is just a number, whereas excess flow storage consumes space that may need to be paid for.Zanie
git
command from python to see if the flow should be registered. (also note, you can control building of the flow’s storage during registration with the build: bool
kwarg)Amanda Wee
01/19/2021, 7:12 PMserialized_hash()
with a combined hash of the dependency management lockfile, the files containing code common to the flows, the files containing that particular flow (or rather project), and the cron string for the flow as supplied by an environment variable. So this way the flow only gets bumped in version if there's a dependency, code, or schedule change. Is this potentially problematic?
I understand that a flow doesn't need to be re-registered if its task code changes, as long as the task DAG remains the same. Is this correct?
Does a flow need to be re-registered if a schedule specified via code (CronSchedule
) changes? It seems that way to me because such a schedule is listed as read-only by the web UI, hence re-registering seems the only way to update that kind of schedule.Zanie
Amanda Wee
01/19/2021, 7:17 PMZanie