Revanth14 opened a new pull request, #68700:
URL: https://github.com/apache/airflow/pull/68700

   closes: #68382
   
   ## What
   
   Connection `port` accepted any integer, so values outside the valid TCP/UDP 
range: `0`, `-1`, `99999999` were silently persisted and only surfaced later as 
confusing failures deep inside provider hooks. This validates that `port` is 
within **1–65535** at every boundary where a connection is *created*, catching 
the problem at the source.
   
   
   
   ## Where Validation Is Enforced
   
   - **REST API** — `ConnectionBody` now constrains `port` with `ge=1, 
le=65535`, so `POST`/`PATCH`/bulk and the connection-test endpoint return `422` 
for an out-of-range port. The generated OpenAPI spec is regenerated to match.
   - **CLI** — `airflow connections add` (`--conn-port` is now typed, and range 
errors surface as a clean `SystemExit`) and `airflow connections import`.
   - **Models** — `Connection(...)` / `Connection(uri=...)` and 
`Connection.from_json(...)` in core, plus `Connection(...)`, 
`Connection.from_uri(...)`, and `Connection.from_json(...)` in the Task SDK.
   
   Port handling is split into `_coerce_port` (type coercion: `str` → `int`, 
reject `bool`/non-integer) and `_normalize_port` (coerce + range check), so the 
two concerns are explicit and reused consistently.
   
   ## Handling Existing Data
   
   The change deliberately validates only on **create/write** and stays 
tolerant on **read**, so deployments with connections already storing a 
now-invalid port keep working:
   
   - **No DB change** — no migration and no `CHECK` constraint, so existing 
rows are never re-validated.
   - **Response schema unconstrained** — only the request model carries the 
range, so `GET` still serializes a legacy `port=0` connection.
   - **Secrets backends read tolerantly** — the shared secrets-backend 
deserialization, `LocalFilesystemBackend`, the env-var backend, and the 
in-worker secret cache all pass `validate_port=False`, so a connection stored 
in Vault / AWS Secrets Manager / a local file / `AIRFLOW_CONN_*` with a legacy 
port still loads. A small signature-introspection shim keeps this compatible 
with older published Task SDK `Connection` classes that do not yet accept the 
flag.
   
   Per review guidance, port `0` is rejected on creation, but tolerated when 
reading pre-existing data.
   
   ## Tests
   
   Added coverage for valid/invalid ports across the model, Task SDK, REST API, 
and both CLI commands; for read-tolerance of legacy ports through the metadata 
DB, local-filesystem and env-var secrets backends, and the shared 
deserialization path; and for the cross-version shim.
   
   Validation run locally:
   
   - `uv run --project shared/secrets_backend pytest 
shared/secrets_backend/tests/secrets_backend/test_base.py -xvs`
   - `uv run --project airflow-core pytest 
airflow-core/tests/unit/models/test_connection.py 
airflow-core/tests/unit/always/test_secrets_backends.py 
airflow-core/tests/unit/always/test_secrets_local_filesystem.py -xvs`
   - `uv run --project airflow-core pytest 
airflow-core/tests/unit/cli/commands/test_connection_command.py -xvs`
   - `uv run --project airflow-core pytest 
airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_connections.py 
-xvs`
   - `uv run --project task-sdk pytest 
task-sdk/tests/task_sdk/definitions/test_connection.py 
task-sdk/tests/task_sdk/execution_time/test_context.py::TestSecretsBackend::test_get_connection_allows_legacy_invalid_port
 
task-sdk/tests/task_sdk/execution_time/test_context.py::TestSecretsBackend::test_get_connection_uses_backend_chain
 
task-sdk/tests/task_sdk/execution_time/test_supervisor.py::test_fetch_remote_logging_conn_does_not_cache_none_result
 -xvs`
   - `prek run ruff --from-ref upstream/main`
   - `prek run ruff-format --from-ref upstream/main`
   - `prek run mypy-shared-secrets_backend --all-files`
   - `prek run ts-compile-lint-ui --from-ref upstream/main`
   
   ---
   
   ##### Was generative AI tooling used to co-author this PR?
   
   - [X] Yes — Codex (GPT-5.5)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to