Airflow breaks after authenticating when using `astro dev start` about astro-cli HOT 18 OPEN

I encountered the same issue yesterday using astro runtime 11.0.0.

I managed to get it working using the below steps. I'm not sure if all these steps are necessary.

1. Installed the astro-cli 1.26.0 (pre-release)
2. Ran the command astro dev kill
3. Made sure any airflow docker volumes were removed
4. Change the version to 11.1.0
5. Ran the command astro dev start like usual and logged in without error.

UPDATE: @FrikadelleHelle confirmed that only upgrading to runtime 11.1.0 was necessary.

UPDATE 2: It looks each time a new runtime version is released, local development breaks for prior 11.x.x versions. Using the latest runtime version appears to let you continue working locally.

from astro-cli.

I just had this error (with same steps to reproduce) on 11.0.0. I bumped to the image to 11.1.0, and it "worked" for a couple days until I ran some very long running, very data intensive jobs (possibly unrelated). Eventually 11.1.0 gave the same error after login - same stacktrace ending in KeyError: 'can_dismiss'.

So I don't think the issue is resolved in 11.1.0, it's just starting with a fresh environment. I see in the stacktrace a reference to astronomer/airflow/version_check/templates/update-available.html and 11.2.0 was just released (possibly related?). Regardless, I guess it's time to bump the version again and hope it's actually resolved in this next release 🤞 ...

from astro-cli.

encountering with 11.2.0 as of yesterday

Yes, the issue is with custom plugin code that runs when a new version exists. It was now fixed in 11.3.0 and wont occur on 11.3.0 or later. :)

from astro-cli.

What @keithbentrup says seems correct, and this issue has started in runtime 11.0.0. As of now, you can no longer run a local instance of Astro if you are not on the last runtime release when you use major version 11.

from astro-cli.

Hi :)

This is likely related to this issue: apache/airflow#39144 (which will be fixed in Airflow 2.9.1)

As a workaround you can either set AIRFLOW__ASTRONOMER__UPDATE_CHECK_INTERVAL=0 or, since the issue only occurs if there is a newer Runtime version, use version (EDIT:) 11.3.0. The issue is fixed as of 11.3.0.

from astro-cli.

Same issue, any possible solution to this?

from astro-cli.

Nice! Only upgrading to runtime 11.1.0 worked for me. Wasn't sure what was meant at first, as im new to our astro deployment, so for anyone in same boat:

I went to the Dockerfile in the project and changed the image tag to
FROM quay.io/astronomer/astro-runtime:11.1.0

I guess that its just a workaround still

from astro-cli.

I confirmed, I had the same issue and I upgrade the runtime from 11.2.0 to 11.3.0 as suggested. Problem solved

from astro-cli.

I encountered the same problem. From the error description it seems to be caused by the fact that version 11.1.0 was recently released. I tried upgrading but that didn't solve it. A solution was going back to an older version 10.6.0. But i had to delete my docker volumes.

from astro-cli.

Nice! Only upgrading to runtime 11.1.0 worked for me. Wasn't sure what was meant at first, as im new to our astro deployment, so for anyone in same boat:

I went to the Dockerfile in the project and changed the image tag to FROM quay.io/astronomer/astro-runtime:11.1.0

I guess that its just a workaround still

I'm glad you got it working! It's very much a workaround.

from astro-cli.

It is still not working for me. Exact same error on Macbook pro with M3 pro.

Astro CLI 1.26.0
Airflow 2.9.0+astro.1
macOS Sonoma 14.4.1
Python 3.11.9

from astro-cli.

encountering with 11.2.0 as of yesterday

from astro-cli.

2.9.1/11.3 has been working for us too, however, as of today it stopped working. I noticed that 11.4 was released today, I'm not sure if this is related.

from astro-cli.

2.9.1/11.3 has been working for us too, however, as of today it stopped working. I noticed that 11.4 was released today, I'm not sure if this is related.

Hi! I think that is could be a separate issue. I just tested 11.3.0 on a fresh, empty Astro CLI project and am not getting any errors.
apache/airflow#39167 and apache/airflow#39421 should have fixed this, though you might have found an edge case.

Can you please file a new issue with some additional information about your set up? :)

from astro-cli.

The underlying issue does not appear to be fixed and setting AIRFLOW__ASTRONOMER__UPDATE_CHECK_INTERVAL=0 still works as a workaround.

from astro-cli.

@rajukrishnamurthy can you provide your dockerfile and requirements.txt? If not, can you try experimenting to identify a minimal reproduction that you can share? That would be very helpful. I suspect something in those files are causing the issue to continue happening.

from astro-cli.

@jedcunningham we use bazel as our build system and we have a custom macro that creates the image, so there's not a dockerfile and an minimal example is going to be hard to create. I'm assuming that needing update_check_interval means that we have some older dependency that doesn't contain the two fix, let me check that and I'll report back.

from astro-cli.

@rajukrishnamurthy can you run pip freeze | grep apache-airflow in your image? 2 packages matter here afaik, apache-airflow-providers-fab>=1.1.0 and apache-airflow>=2.9.1+astro.1.

from astro-cli.