Skip to content

Connection health check #17498

Closed
Closed

Description

@malthe

Description

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.

Are you willing to submit a PR?

Yes

Related Issues

Activity

  1. BasPH commented on Aug 9, 2021

    @BasPH
    Contributor

    I realize your issue suggests different behaviour, but linking this here for reference #15795

  2. malthe commented on Aug 9, 2021

    @malthe
    ContributorAuthor

    @BasPH oh awesome – when is this coming to an Airflow release? I don't see it in the latest 2.1.2 release.

  3. BasPH commented on Aug 9, 2021

    @BasPH
    Contributor

    It's currently set for Airflow 2.2 (you can see a "Milestone" section in the PR).

  4. uranusjr commented on Oct 27, 2021

    @uranusjr
    Member

    How should we proceed now 2.2 is released?

  5. added this to the Airflow 2.2.0 milestone on Oct 27, 2021
  6. linked a pull request that will close this issueAbility to test connections from UI or API #15795on Oct 27, 2021
  7. potiuk commented on Oct 27, 2021

    @potiuk
    Member

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions