Airflow breaks after authenticating when using astro dev start
#1629
Comments
|
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. |
|
Same issue, any possible solution to this? |
|
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.
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. |
|
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 I guess that its just a workaround still |
I'm glad you got it working! It's very much a workaround. |
|
It is still not working for me. Exact same error on Macbook pro with M3 pro. Astro CLI 1.26.0 |
|
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 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 |
|
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. |
|
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 |
|
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. :) |
|
I confirmed, I had the same issue and I upgrade the runtime from 11.2.0 to 11.3.0 as suggested. Problem solved |
|
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. Can you please file a new issue with some additional information about your set up? :) |
|
The underlying issue does not appear to be fixed and setting |
|
@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. |
|
@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. |
|
@rajukrishnamurthy can you run |
Describe the bug
I am using the Astro CLI to boot airflow locally and get redirected to the login screen. But after
The issue has also been created here: apache/airflow#39170, but it seems to be a astro specific thing.
This is the logs from
astro dev logsWhat CLI Version did you experience this bug?
Astro CLI Version: 1.25.0
This CLI bug is related to which Astronomer Platform?
What Operating System is the above CLI installed on?
macOS Sonoma 14.2.1 (23C71)
🪜 Steps To Reproduce
astro dev startadmin:adminThe text was updated successfully, but these errors were encountered: