[jira] [Created] (AIRFLOW-1851) next/previous buttons on DAG Tree View UI
Tylar Murray created AIRFLOW-1851: - Summary: next/previous buttons on DAG Tree View UI Key: AIRFLOW-1851 URL: https://issues.apache.org/jira/browse/AIRFLOW-1851 Project: Apache Airflow Issue Type: New Feature Components: webapp Reporter: Tylar Murray Priority: Minor I would be surprised if this was not already requested/documented somewhere, but I was not able to find it. Next and Previous buttons in the webapp tree view would be very useful for me. Currently I have to look at the earliest/latest run showing and adjust the Base date manually to "page" through tasks. Seems pretty straightforward so it might make a good first issue, but then again I have no idea what the webapp code looks like. I'm happy to provide more info on request, but I think that about covers it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (AIRFLOW-2459) Unable to insert in log table while using MySQL
[
https://issues.apache.org/jira/browse/AIRFLOW-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474504#comment-16474504
]
Tylar Murray commented on AIRFLOW-2459:
---
https://dba.stackexchange.com/questions/48704/mysql-5-6-datetime-incorrect-datetime-value-2013-08-25t17-with-er
> Unable to insert in log table while using MySQL
> ---
>
> Key: AIRFLOW-2459
> URL: https://issues.apache.org/jira/browse/AIRFLOW-2459
> Project: Apache Airflow
> Issue Type: Bug
> Components: db
>Affects Versions: Airflow 2.0
>Reporter: kunal gupta
>Priority: Major
> Fix For: Airflow 2.0
>
> Attachments: image-2018-05-13-00-36-20-872.png
>
>
> When i fire airflow initdb, using MySQL 5.7, im getting an error
> MySQL version:
> mysql Ver 14.14 Distrib 5.7.20-19, for Linux (x86_64) using 6.2
> Airflow 2.0
> MySQL set up for global variables:
> show global variables like '%timestamp%';
> !image-2018-05-13-00-36-20-872.png!
> Error message:
> sqlalchemy.exc.InvalidRequestError: This Session's transaction has been
> rolled back due to a previous exception during flush. To begin a new
> transaction with this Session, first issue Session.rollback(). Original
> exception was: (_mysql_exceptions.OperationalError) (1292, "Incorrect
> datetime value: '2018-05-13 05:24:37.946481+00:00' for column 'dttm' at row
> 1") [SQL: u'INSERT INTO log (dttm, dag_id, task_id, event, execution_date,
> owner, extra) VALUES (%s, %s, %s, %s, %s, %s, %s)'] [parameters:
> (datetime.datetime(2018, 5, 13, 5, 24, 37, 946481,
> tzinfo=), None, None,
> 'cli_scheduler', None, 'default', '{"full_command": "[\'/usr/bin/airflow\',
> \'scheduler\']", "host_name": "airflow-35-8jn6w"}')]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AIRFLOW-695) Retries do not execute because dagrun is in FAILED state
[
https://issues.apache.org/jira/browse/AIRFLOW-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491080#comment-16491080
]
Tylar Murray commented on AIRFLOW-695:
--
I believe I am seeing this issue using airflow 1.9.0. What is the fix version
for this bug? Given that this was committed over a year ago I wouldn't expect
to see this in 1.9.0
> Retries do not execute because dagrun is in FAILED state
>
>
> Key: AIRFLOW-695
> URL: https://issues.apache.org/jira/browse/AIRFLOW-695
> Project: Apache Airflow
> Issue Type: Bug
> Components: DagRun
>Reporter: Harvey Xia
>Priority: Blocker
> Labels: executor, scheduler
>
> Currently on the latest master commit
> (15ff540ecd5e60e7ce080177ea3ea227582a4672), running on the LocalExecutor,
> retries on tasks do not execute because the state of the corresponding dagrun
> changes to FAILED. The task instance then gets blocked because "Task
> instance's dagrun was not in the 'running' state but in the state 'failed',"
> the error message produced by the following lines:
> https://github.com/apache/incubator-airflow/blob/master/airflow/ti_deps/deps/dagrun_exists_dep.py#L48-L50
> This error can be reproduced with the following simple DAG:
> {code:title=DAG.py|borderStyle=solid}
> dag = models.DAG(dag_id='test_retry_handling')
> task = BashOperator(
> task_id='test_retry_handling_op',
> bash_command='exit 1',
> retries=1,
> retry_delay=datetime.timedelta(minutes=1),
> dag=dag,
> owner='airflow',
> start_date=datetime.datetime(2016, 2, 1, 0, 0, 0))
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AIRFLOW-2535) TriggerDagRunOperator ignores max_active_runs, leading to scheduler breakdown
Tylar Murray created AIRFLOW-2535: - Summary: TriggerDagRunOperator ignores max_active_runs, leading to scheduler breakdown Key: AIRFLOW-2535 URL: https://issues.apache.org/jira/browse/AIRFLOW-2535 Project: Apache Airflow Issue Type: Bug Components: operators, scheduler Affects Versions: 1.9.0 Environment: CeleryExec, Rabbitmq, mysql Reporter: Tylar Murray `TriggerDagRunOperator` does not respect the `max_active_runs` setting. This in itself is not a huge issue, but the scheduler breaks down if `max_active_runs` is exceeded. Task scheduling becomes absurdly slow quickly leading to perpetual DAG buildup. `TriggerDagRunOperator` could throw exception if `max_active_runs` will be exceeded, or maybe dags could be put into a `queued` state rather than directly into `running`? Alternatively: the scheduler probably shouldn't slow task scheduling when `max_active_runs` is exceeded. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AIRFLOW-2535) TriggerDagRunOperator ignores max_active_runs, leading to scheduler breakdown
[ https://issues.apache.org/jira/browse/AIRFLOW-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tylar Murray updated AIRFLOW-2535: -- Description: `TriggerDagRunOperator` does not respect the `max_active_runs` setting. This in itself is not a huge issue, but the scheduler breaks down if `max_active_runs` is exceeded. Task scheduling becomes absurdly slow, quickly leading to perpetual DAG buildup. `TriggerDagRunOperator` could throw exception if `max_active_runs` will be exceeded, or maybe dags could be put into a `queued` state rather than directly into `running`? Alternatively: the scheduler probably shouldn't slow task scheduling when `max_active_runs` is exceeded. was: `TriggerDagRunOperator` does not respect the `max_active_runs` setting. This in itself is not a huge issue, but the scheduler breaks down if `max_active_runs` is exceeded. Task scheduling becomes absurdly slow quickly leading to perpetual DAG buildup. `TriggerDagRunOperator` could throw exception if `max_active_runs` will be exceeded, or maybe dags could be put into a `queued` state rather than directly into `running`? Alternatively: the scheduler probably shouldn't slow task scheduling when `max_active_runs` is exceeded. > TriggerDagRunOperator ignores max_active_runs, leading to scheduler breakdown > - > > Key: AIRFLOW-2535 > URL: https://issues.apache.org/jira/browse/AIRFLOW-2535 > Project: Apache Airflow > Issue Type: Bug > Components: operators, scheduler >Affects Versions: 1.9.0 > Environment: CeleryExec, Rabbitmq, mysql >Reporter: Tylar Murray >Priority: Minor > > `TriggerDagRunOperator` does not respect the `max_active_runs` setting. This > in itself is not a huge issue, but the scheduler breaks down if > `max_active_runs` is exceeded. Task scheduling becomes absurdly slow, quickly > leading to perpetual DAG buildup. > `TriggerDagRunOperator` could throw exception if `max_active_runs` will be > exceeded, or maybe dags could be put into a `queued` state rather than > directly into `running`? > Alternatively: the scheduler probably shouldn't slow task scheduling when > `max_active_runs` is exceeded. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AIRFLOW-2049) Detailed documentation on airflow.cfg options
Tylar Murray created AIRFLOW-2049: - Summary: Detailed documentation on airflow.cfg options Key: AIRFLOW-2049 URL: https://issues.apache.org/jira/browse/AIRFLOW-2049 Project: Apache Airflow Issue Type: Improvement Components: Documentation Reporter: Tylar Murray The only documentation on the configuration options in the airflow.cfg file are the short summaries in the file itself. I would like to see a more detailed documentation of the options in the file included in the official docs. I am currently troubleshooting an under-performing cluster and have been guessing at what options I should adjust. I would be happy to research & write additional docs for this, but I am fairly new to airflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AIRFLOW-1737) set_task_instance_state fails because of strptime
[ https://issues.apache.org/jira/browse/AIRFLOW-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581268#comment-16581268 ] Tylar Murray commented on AIRFLOW-1737: --- https://github.com/apache/incubator-airflow/pull/3754 > set_task_instance_state fails because of strptime > - > > Key: AIRFLOW-1737 > URL: https://issues.apache.org/jira/browse/AIRFLOW-1737 > Project: Apache Airflow > Issue Type: Bug > Components: webapp >Reporter: Andre Boechat >Assignee: Tao Feng >Priority: Minor > Attachments: Screenshot_2017-10-18_15-58-29.png > > > Context: > * DAG run triggered manually > * Using the web application to change the state of a task > When trying to set the state of a task, an exception is thrown: *ValueError: > unconverted data remains: ..372649* (look at the attached screenshot). > I think the problem comes from the "execution date" created by manually > triggered DAGs, since the date-time includes a fractional part. In my > database, I see scheduled DAGs with execution dates like "10-18T15:00:00", > while manually triggered ones with dates like "09-21T16:36:16.170988". If we > look at the method *set_task_instance_state* in *airflow.www.views*, we see > that the format string used with *strptime* doesn't consider any fractional > part. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AIRFLOW-2768) `airflow clear --upstream --only_failed` doesn't clear tasks upstream
[ https://issues.apache.org/jira/browse/AIRFLOW-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549396#comment-16549396 ] Tylar Murray commented on AIRFLOW-2768: --- It looks like `–rerun_failed_tasks` was added in `1.10` so I do not have the option in `1.9`. From the description it doesn't **sound** like what I want, but maybe it is? I can "auto rerun only the failed task" with `airflow clear --only_failed`. I want to rerun all tasks (even non-failed) within a failed DagRun. > `airflow clear --upstream --only_failed` doesn't clear tasks upstream > - > > Key: AIRFLOW-2768 > URL: https://issues.apache.org/jira/browse/AIRFLOW-2768 > Project: Apache Airflow > Issue Type: Bug > Components: cli >Affects Versions: 1.9.0 > Environment: airflow v1.9.0 >Reporter: Tylar Murray >Priority: Major > Labels: cli > > Should `airflow clear --upstream --only_failed mydagname` clear non-failed > tasks upstream of a failed task? > I believe so, yes. If not, then `airflow clear --upstream --only_failed` and > `airflow clear --only_failed` are equivalent. > Upstream tasks are not being cleared. The same is true for `–downstream`. > > My use-case is: I want to clear all tasks all DagRuns that contain a failed > task. In other words: `airflow clear mydagname`, but skip DagRuns that have > completed sucessfully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AIRFLOW-2768) `airflow clear --upstream --only_failed` doesn't clear tasks upstream
Tylar Murray created AIRFLOW-2768: - Summary: `airflow clear --upstream --only_failed` doesn't clear tasks upstream Key: AIRFLOW-2768 URL: https://issues.apache.org/jira/browse/AIRFLOW-2768 Project: Apache Airflow Issue Type: Bug Components: cli Affects Versions: 1.9.0 Environment: airflow v1.9.0 Reporter: Tylar Murray Should `airflow clear --upstream --only_failed mydagname` clear non-failed tasks upstream of a failed task? I believe so, yes. If not, then `airflow clear --upstream --only_failed` and `airflow clear --only_failed` are equivalent. Upstream tasks are not being cleared. The same is true for `–downstream`. My use-case is: I want to clear all tasks all DagRuns that contain a failed task. In other words: `airflow clear mydagname`, but skip DagRuns that have completed sucessfully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AIRFLOW-1305) This DAG seems to be exists locally.
[ https://issues.apache.org/jira/browse/AIRFLOW-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16556284#comment-16556284 ] Tylar Murray commented on AIRFLOW-1305: --- After running into this myself using airflow v1.9.0 and confirming that the issue was with the dag table in the database. In general the cause seems to be that the scheduler and webserver are unable to reconcile differences between the database and the filesystem. The steps I would suggest to resolve this are: # check permissions on dag definition files to ensure airflow can read the files # restart scheduler and webserver in hopes they can work things out after restart # `airflow initdb` to reset the dag table using the filesystem Anecdotally, `initdb` doesn't affect any dags that still exist, but it will clear dags not found on the filesystem and add ones on the filesystem but missing from the database. > This DAG seems to be exists locally. > > > Key: AIRFLOW-1305 > URL: https://issues.apache.org/jira/browse/AIRFLOW-1305 > Project: Apache Airflow > Issue Type: Bug >Reporter: Ting >Priority: Critical > Attachments: 702EE4FC-4E15-490C-AB2B-E2BFAFEB36D7.png > > > All DAGs I created after tutorial show like this, and I can not make it on or > off in UI. > Restart webserver, no use to this. > Also, the dags are not scheduled. > Hope for useful help. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AIRFLOW-1515) Airflow 1.8.1 tasks not being marked as upstream_failed when one of the parents fails
[ https://issues.apache.org/jira/browse/AIRFLOW-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tylar Murray updated AIRFLOW-1515: -- Attachment: image-2018-04-03-21-24-58-893.png > Airflow 1.8.1 tasks not being marked as upstream_failed when one of the > parents fails > - > > Key: AIRFLOW-1515 > URL: https://issues.apache.org/jira/browse/AIRFLOW-1515 > Project: Apache Airflow > Issue Type: Bug > Components: core, DAG, DagRun >Affects Versions: 1.8.1 >Reporter: Jose Sanchez >Priority: Major > Attachments: airflow_bug.png, image-2018-04-03-21-24-58-893.png, > rofl_test.py > > > the trigger rule "all_done" is not working when its parents are marked as > State.None instead of State.Upstream_Failed. I am submitting a very small dag > as example and a picture of the run, where the last Task should have been > executed before marking the dag as failed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AIRFLOW-1515) Airflow 1.8.1 tasks not being marked as upstream_failed when one of the parents fails
[ https://issues.apache.org/jira/browse/AIRFLOW-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424635#comment-16424635 ] Tylar Murray commented on AIRFLOW-1515: --- [~ivan.vergiliev]: I don't think the issue here is with the evaluation of the rule, the problem as I understand it is that tasks downstream from a failed task are never queued and thus their state stays `None` forever. Here is a treeview which I believe demonstrates the issue: !image-2018-04-03-21-24-58-893.png! Here `tmp_cleanup` is set to `all_done` because we want to cleanup whether things fail or not. This works if an immediate parent fails (`load_att_wv2_m1bs`), but not if a *-grandparent fails (`rm_spurrious_gis_files` or `unzip_wv2_ingest`) because `UPSTREAM_FAILED` never propagates down. > Airflow 1.8.1 tasks not being marked as upstream_failed when one of the > parents fails > - > > Key: AIRFLOW-1515 > URL: https://issues.apache.org/jira/browse/AIRFLOW-1515 > Project: Apache Airflow > Issue Type: Bug > Components: core, DAG, DagRun >Affects Versions: 1.8.1 >Reporter: Jose Sanchez >Priority: Major > Attachments: airflow_bug.png, image-2018-04-03-21-24-58-893.png, > rofl_test.py > > > the trigger rule "all_done" is not working when its parents are marked as > State.None instead of State.Upstream_Failed. I am submitting a very small dag > as example and a picture of the run, where the last Task should have been > executed before marking the dag as failed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AIRFLOW-1515) Airflow 1.8.1 tasks not being marked as upstream_failed when one of the parents fails
[ https://issues.apache.org/jira/browse/AIRFLOW-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424614#comment-16424614 ] Tylar Murray commented on AIRFLOW-1515: --- Is this fixed in 1.9? I am finding this to be a big pain to work around and would rather upgrade if that fixes it. > Airflow 1.8.1 tasks not being marked as upstream_failed when one of the > parents fails > - > > Key: AIRFLOW-1515 > URL: https://issues.apache.org/jira/browse/AIRFLOW-1515 > Project: Apache Airflow > Issue Type: Bug > Components: core, DAG, DagRun >Affects Versions: 1.8.1 >Reporter: Jose Sanchez >Priority: Major > Attachments: airflow_bug.png, rofl_test.py > > > the trigger rule "all_done" is not working when its parents are marked as > State.None instead of State.Upstream_Failed. I am submitting a very small dag > as example and a picture of the run, where the last Task should have been > executed before marking the dag as failed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
