OpenLineage defaults in airflow.cfg incorrect about airflow HOT 4 OPEN

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

from airflow.

@mobuchowski would love your thoughts on this one

from airflow.

I don't think this is about defaults. We need to know the history of what happened to the airflow.cfg you refer to @merobi-hub ? and where the values were taken from - but this is not about "defaults".

From what I see, default for this parameter is empty. And you have to manually set it. And example explaining it changed in #37620 to include the endpoint.

When you run:

airflow config list --defaults

You get this:

# Pass OpenLineage Client transport configuration as JSON string. It should contain type of the
# transport and additional options (different for each transport type). For more details see:
# https://openlineage.io/docs/client/python/#built-in-transport-types
#
# Currently supported types are:
#
#   * HTTP
#   * Kafka
#   * Console
#   * File
#
# Example: transport = {"type": "http", "url": "http://localhost:5000", "endpoint": "api/v1/lineage"}
#
# Variable: AIRFLOW__OPENLINEAGE__TRANSPORT
#
# transport =

So the "endpoint" is mentioned in example, but defaults are empty. Previously indeed the example did not have endpoint and previous versions of openlineage provider accepted it this way.

So I presume (@merobi-hub?) that this is all about "What do we do if the users used previous version of the openlineage, configured it and now with the new version of openlineage it does not work" - so it's more of a migration issue ?

My suggestion would be - if really "endpoint" is needed - to add it automatically if missing and raise a warning that confiiguration should be updated.

We did something similar with auth_backends parameter of api session - where in new version of it we expect "session" backend to be explicitly added, but in some old versions it was not needed, so we add it automatically if missing and raise a warning for the user to update their configuration.

    def _upgrade_auth_backends(self):
        """
        Ensure a custom auth_backends setting contains session.

        This is required by the UI for ajax queries.
        """
        old_value = self.get("api", "auth_backends", fallback="")
        if old_value in ("airflow.api.auth.backend.default", ""):
            # handled by deprecated_values
            pass
        elif old_value.find("airflow.api.auth.backend.session") == -1:
            new_value = old_value + ",airflow.api.auth.backend.session"
            self._update_env_var(section="api", name="auth_backends", new_value=new_value)
            self.upgraded_values[("api", "auth_backends")] = old_value

            # if the old value is set via env var, we need to wipe it
            # otherwise, it'll "win" over our adjusted value
            old_env_var = self._env_var_name("api", "auth_backend")
            os.environ.pop(old_env_var, None)

            warnings.warn(
                "The auth_backends setting in [api] has had airflow.api.auth.backend.session added "
                "in the running config, which is needed by the UI. Please update your config before "
                "Apache Airflow 3.0.",
                FutureWarning,
                stacklevel=1,
            )

from airflow.

I'm not sure if the empty endpoint is the issue here, as it has a default value of api/v1/lineage defined in HttpConfig in OpenLineageClient (added two years ago). So no matter if you provide {"type": "http", "url": "http://localhost:5000/"} or {"type": "http", "url": "http://localhost:5000", "endpoint": "api/v1/lineage"}, it should create exactly the same transport (it's reading the transport and directly calling OL client here, then the default factory is creating the HttpConfig).

I was able to successfully receive event on http://127.0.0.1:5000/api/v1/lineage when specyfying the transport as {"type": "http", "url": "http://127.0.0.1:5000"} using apache-airflow-providers-openlineage==1.5.0

Could you please verify what is being that transport created in both scenarios is actually different (when it's working and not working, as I'm unable to reproduce this)? Something like:

from airflow.providers.openlineage.plugins.openlineage import get_openlineage_listener

print(get_openlineage_listener().adapter._client.transport)

from airflow.