This problem seems to persist actually. I had a dag with dag_id "redshift_vacuum". In reworking the dag (and significantly changing the schedule) I renamed it to "redshift_vacuum_v2". However after deploying to production I now see the original "redshift_vacuum" dag (with the little tool-tip saying it's not in the DagBag but is in the metadata). Looking at the airflow DB it is indeed is_active=t.
On Tue, Mar 21, 2017 at 4:28 PM, Vijay Ramesh <vi...@change.org> wrote: > Not sure if this is actually worth filing a bug report about, but we were > running the 1.8.0-rc4 release. This past Friday I upgraded to the -rc5 > release (after the -rc4 package got pulled and was breaking our chef > cookbooks). Everything went smoothly, but a handful of DAGs reappeared in > the web-server, with a little tooltip note that they aren't in the dag bag > but they are in the scheduler DB. > > Sure enough, our postgres db shows them as is_active = t. I manually set > them back to f and everything seems fine. But still odd behavior, and it > happened in both staging & production during the rc4 => rc5 release. > > Thanks again for all the hard work on 1.8.0! I updated our cookbooks > today to pull from pypi now that it is official. > > - Vijay >
