You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add an option to enable a "Connection health check" on a connection.
This would have the effect that a background connection test would be scheduled to run with a configurable interval (globally configured). The test would be executed by a worker.
If one or more connection health checks currently fail, a message on the main page will be shown. In addition, the connection list will show a health status for each entry.
Use case / motivation
It's previously been proposed to run a connection check as part of saving a new connection through the Airflow UI (see related issues below).
But such a health check is really an on-going concern – similar to how DAG input files are scanned for syntax errors and reported on the main page.
@uranusjr: We mark it for milestone 2.2.0, we link the issue manualy (sometimes linking PR from issue does not work but usually it works the other way -- you can go to PR and link the issue to the PR 🤷 .
Then we close the issue.
This is the GREAT by-product of making PR#s as our "changelog entries". After such update - we do not have to modify the changelog because the PR that fixed it has been (had to be) correctly mentioned in the changelog. Linking the issue to such closed PR just "refines" the state of the issue and makes it synced with the PR which is already in the changelog.
Activity
BasPH commentedon Aug 9, 2021
I realize your issue suggests different behaviour, but linking this here for reference #15795
malthe commentedon Aug 9, 2021
@BasPH oh awesome – when is this coming to an Airflow release? I don't see it in the latest 2.1.2 release.
BasPH commentedon Aug 9, 2021
It's currently set for Airflow 2.2 (you can see a "Milestone" section in the PR).
uranusjr commentedon Oct 27, 2021
How should we proceed now 2.2 is released?
potiuk commentedon Oct 27, 2021
@uranusjr: We mark it for milestone 2.2.0, we link the issue manualy (sometimes linking PR from issue does not work but usually it works the other way -- you can go to PR and link the issue to the PR 🤷 .
Then we close the issue.
This is the GREAT by-product of making PR#s as our "changelog entries". After such update - we do not have to modify the changelog because the PR that fixed it has been (had to be) correctly mentioned in the changelog. Linking the issue to such closed PR just "refines" the state of the issue and makes it synced with the PR which is already in the changelog.