An Edge worker reports its Airflow and Edge provider versions when it registers. With a minimum acceptable worker version configured, the API server parses those versions, and a bad value from the worker returned HTTP 500 instead of a client error. Two inputs hit this: a string that is not a valid version, and a version sent as a number, which the request schema accepts.

The API now answers both with HTTP 400 and a message naming the bad value, as the route already documents. A bad minimum version in the server config still returns 500, because that is a server misconfiguration rather than bad worker input.

Testing Done

Registered workers through the real worker route with a minimum core version of 0.0.0, sending three bad core versions. Each run covers packaging 25.0 and the locked 26.3, because a numeric version fails differently on them: 26.2 and older raise TypeError, 26.3 raises InvalidVersion.

Before, with worker.py from apache/main:

git show apache/main:providers/edge3/src/airflow/providers/edge3/worker_api/routes/worker.py > providers/edge3/src/airflow/providers/edge3/worker_api/routes/worker.py
uv run --project providers/edge3 --with packaging==25.0 python repro_worker_version.py
uv run --project providers/edge3 python repro_worker_version.py

packaging 25.0
  'invalid-version': HTTP 500 Internal Server Error
  3: HTTP 500 Internal Server Error
  3.5: HTTP 500 Internal Server Error
packaging 26.3
  'invalid-version': HTTP 500 Internal Server Error
  3: HTTP 500 Internal Server Error
  3.5: HTTP 500 Internal Server Error

After, on this branch:

git checkout -- providers/edge3/src/airflow/providers/edge3/worker_api/routes/worker.py
uv run --project providers/edge3 --with packaging==25.0 python repro_worker_version.py
uv run --project providers/edge3 python repro_worker_version.py

packaging 25.0
  'invalid-version': HTTP 400 {"detail":"Invalid version string 'invalid-version': Invalid version: 'invalid-version'"}
  3: HTTP 400 {"detail":"Invalid version 3: expected a string, got int"}
  3.5: HTTP 400 {"detail":"Invalid version 3.5: expected a string, got float"}
packaging 26.3
  'invalid-version': HTTP 400 {"detail":"Invalid version string 'invalid-version': Invalid version: 'invalid-version'"}
  3: HTTP 400 {"detail":"Invalid version 3: expected a string, got int"}
  3.5: HTTP 400 {"detail":"Invalid version 3.5: expected a string, got float"}

import os

os.environ["AIRFLOW__API_AUTH__JWT_SECRET"] = "repro-secret"
os.environ["AIRFLOW__EDGE__MINIMUM_ACCEPTABLE_CORE_VERSION_FOR_WORKERS"] = "0.0.0"

import packaging
from fastapi import FastAPI
from fastapi.testclient import TestClient

from airflow.api_fastapi.auth.tokens import JWTGenerator
from airflow.providers.edge3 import __version__ as edge_provider_version
from airflow.providers.edge3.worker_api.routes.worker import worker_router

app = FastAPI()
app.include_router(worker_router, prefix="/edge_worker/v1")
token = JWTGenerator(secret_key="repro-secret", valid_for=60, audience="api").generate(
    extras={"method": "worker/repro"}
)
print(f"packaging {packaging.__version__}")
with TestClient(app, raise_server_exceptions=False, headers={"Authorization": token}) as client:
    for worker_version in ("invalid-version", 3, 3.5):
        sysinfo = {"airflow_version": worker_version, "edge_provider_version": edge_provider_version}
        response = client.post("/edge_worker/v1/worker/repro", json={"state": "starting", "sysinfo": sysinfo})
        print(f"  {worker_version!r}: HTTP {response.status_code} {response.text}")

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: GitHub Copilot CLI (GPT-6 Astra) following the guidelines

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.