Comments (18)
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.
- Installed the astro-cli 1.26.0 (pre-release)
- Ran the command
astro dev kill
- Made sure any airflow docker volumes were removed
- Change the version to 11.1.0
- 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.
Related Issues (20)
- Generic connections showing different results in local when compared to astro HOT 3
- Unable to run DockerOperator HOT 4
- BUG: upgrade messing output in deployment files HOT 2
- Airflow UI URL after `astro deploy` is broken HOT 1
- Enable updating deployment dev mode via CLI
- Allow create/edit/delete of kubernetes secrets from Astro CLI
- Improve message for the missed "workspace" option while using Org level tokens
- Warn when an EOL Runtime version is used
- Block action when a yanked Runtime version is used HOT 2
- Feature: `astro-cli deploy -n NAMESPACE`
- Latest CLI versions breaks when trying to create a deployment with the same name as in a different Workspace HOT 1
- Upgrade Test Command doesn't handle errors properly
- `astro login` fails on callback "This site canβt provide a secure connection" HOT 4
- astro workspace switch will take a workspace name and then functionality breaks
- DAGs changes do not always instantly update on local Airflow UI
- When providing a workspace ID longer than 25 characters, the Astro CLI crashes with a runtime error.
- Default 'astro dev init' to ACR images instead of quay.io
- Add more unit test to bump coverage
- Allow passing build args, not just secrets, to relevant `astro dev ...` commands HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from astro-cli.