Aydeing opened a new pull request, #68541: URL: https://github.com/apache/airflow/pull/68541
closes: #68382 Airflow stores a ``port`` field on connections but never validates that the value is a valid TCP/UDP port number. This adds port range validation (1–65535) on **write paths only**, so existing persisted connections with now-invalid port values continue to load via the ORM without errors — addressing the maintainer review concern about not breaking existing installations. ### Where validation is enforced (create/update paths) - **Core connection model** (``airflow.models.connection``) — ``_validate_port()`` static method called in ``__init__`` and ``from_json()``. SQLAlchemy's ``@reconstructor`` does **not** call ``__init__``, so DB loads are unaffected. - **Task SDK connection definition** (``airflow.sdk.definitions.connection``) — attrs ``@port.validator`` + ``from_json()`` validation. - **Public REST API request schema** (``ConnectionBody``) — Pydantic ``Field(ge=1, le=65535)``. - **CLI** (``--conn-port``) — changed ``type=str`` → ``type=int`` for argparse type checking; range validated by the model constructor. ### What is intentionally NOT validated (read/response paths) To avoid breaking existing installations that may have persisted invalid port values: - Execution API ``ConnectionResponse`` — unchanged. - Core API ``ConnectionResponse`` — unchanged. - Generated SDK datamodels (``_generated.py``) — unchanged. - JSON schema (``schema.json``) — unchanged. ### Port 0 is rejected Per maintainer feedback on the issue: since ``port`` is optional (``None`` = no port), port 0 has no valid use case and is rejected. Range is **1–65535**. ### Tests added | File | Tests | |---|---| | ``airflow-core/tests/unit/models/test_connection.py`` | ``test_port_within_valid_range_is_accepted`` (1, 22, 5432, 65535) · ``test_port_none_is_accepted`` · ``test_port_out_of_range_is_rejected`` (0, -1, 65536, 99999) · ``test_from_json_rejects_out_of_range_port`` · ``test_orm_load_tolerates_legacy_invalid_port`` | | ``task-sdk/tests/task_sdk/definitions/test_connection.py`` | Same matrix for the SDK Connection (constructor + ``from_json``) | | ``airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_connections.py`` | ``test_post_should_respond_422_for_out_of_range_port`` (0, -1, 65536, 99999) | | ``airflow-core/tests/unit/cli/commands/test_connection_command.py`` | ``test_cli_connections_add_rejects_out_of_range_port`` · ``test_cli_connections_add_rejects_non_integer_port`` | ## Test plan - [x] Standalone validator harness exercising each enforcement layer: **30/30 checks pass** — confirms ``None``/1/22/5432/65535 accepted, 0/-1/65536/99999 rejected, response schemas tolerate legacy invalid values, ``from_json`` accepts ``"5432"`` and rejects out-of-range strings. - [x] All seven modified source files parse with ``ast.parse``. - [x] ``schema.json`` parses with ``json.loads``. - [x] All four modified test files parse with ``ast.parse``. - [x] ORM-load path verified: ``Connection.__new__(Connection); conn.port = 99999; conn.on_db_load()`` does not raise (legacy data still loads). - [ ] Full ``breeze testing core-tests`` run — requires breeze + Docker, not run locally; will run in CI on this PR. - [ ] ``prek run --from-ref main`` static checks — requires prek hooks installed, will run in CI. ### Notes for reviewers - ``ARG_CONN_PORT`` type changed from ``str`` to ``int``: argparse now rejects non-integer strings at parse time with a clearer error than the downstream ``ValueError`` from ``Connection(...)``. The model still validates the range. - A ``newsfragment`` (e.g. ``<pr_number>.bugfix.rst``) will be added in a follow-up commit once this PR number is assigned, per the PR template guidance. --- ##### Was generative AI tooling used to co-author this PR? - [x] Yes (Claude Code / Anthropic Claude Sonnet 4.6) Generated-by: Claude Sonnet 4.6 following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- 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]
