It's a bit of a hack, but to save up slots you could just have an
instantly-failing PythonOperator (just raise an exception in the callable)
that would go in a failed state. Marking it as "success" when the
conditions are met would act as a trigger.
On Fri, Oct 5, 2018 at 9:07 AM Brian Greene
wro
My first thought was this, but my understanding is That if you had a large
number of dags “waiting” the sensor would consume all the concurrency.
And what if the user doesn’t approve?
How about the dag you have as it’s last step writes to an api/db the status.
Then 2 other dags (or one with a
Hi Björn,
We also sometimes require manual validation, and though we haven't yet
implemented this, I imagine you could store the approved/unapproved status
of the job in a database, expose it via an API, and write an Airflow sensor
that continuously polls that API until the status becomes "approve
Hi all,
In some of our workflows we require a manual validation step, where some
generated data has to be reviewed by an authorised person before the workflow
can continue. We currently model this by using a custom dummy operator that
always fails. After the review, we manually mark it as succe
