-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scheduler getting crashed when downgrading from 2.8.0b1 to 2.7.3 #35914
Comments
I’m getting a different error than the reported error in #35095. The error was reported in 2.5.3.
The UI issue is that you can't see logs |
I have not seen the change before but - this looks like DB structure change implemented without corresponding migration (this is why it has not been detected by our tests - because our tests perform forwards <-> backwards migration and they have not detected it. I think it is indeed generally fishy - and possibly what you see now with different type of error is result of having data writen by the new DB handled by the old code. Yes. I'd be for reverting it. |
cc @PashkPashk |
Sorry, late to the game until I was able to see. I am not sure about this and maybe when I reviewed this I was not considering a "downgrade" case. Is this something we always promise? Technical details here are: It is not a classic structural change of the DB by adding/altering/dropping a column but rather that the previous But in contrast if you Did an upgrade and we implemented (any kind of) new feature and you make a downgrade, is it always promised that new jobs/features consumed can be safely downgraded? In this case it is not a classic "migration" but a new wrapped object class just doing a validation in a new class wrapper. "migration" in such case would mean de-serializing all values in the DB, and writing back the content. This this improvement is not too critical, we might be able to discuss how to handle this, technically it can be re-implemented similar w/o generating the breaking change (with a bit of extra complexity only) |
@jscheffl being able to downgrade after upgrading is something we promise though it's not written but we have some tests that runs migration upgrade and downgrade for different airflow versions. In my view, the field type here is pickletype not JSON and validating it to be JSON is a breaking change. That apart, once you downgrade after upgrading to 2.8 with running task, the scheduler enters a crash loop. Even when you disable task adoption, the scheduler won't recover because the field used synonym and calls ConfDict which no longer exist. In my view, this should be fixed at the params side since in 2.7.3 it's not causing the same problem it caused in 2.5.3 where the problem was reported. I tried different implementations at the dagrun side and all failed. I don't think there's anything else to do their other than changing the field type to JSON which will also cause a breaking change |
Hello! I'm trying to run
|
It's a different issue @Gal40n04ek - I suggest that you open a new discussion and explain exactly the circumstances, database you used, error messages that you got when downgrading / upgrading rather than commenting on closed issue - then there might be a chance someone will help you there. |
Apache Airflow version
2.8.0b1
What happened
The scheduler getting crashed when downgrading from 2.8.0b1 to 2.7.3
we had some running TIs when the downgrade happened, looks like Adopting tasks failing the scheduler.
could be due to this PR
What you think should happen instead
No response
How to reproduce
create 2.8.0b1 deployment
execute a couple of dags
downgrade to 2.7.3
scheduler goes in crash loop
Logs:
Operating System
Linux
Versions of Apache Airflow Providers
No response
Deployment
Astronomer
Deployment details
No response
Anything else
No response
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: