amoghrajesh commented on code in PR #68533:
URL: https://github.com/apache/airflow/pull/68533#discussion_r3411202603
##########
providers/standard/tests/unit/standard/operators/test_python.py:
##########
@@ -1072,8 +1085,9 @@ def test_context(self):
def f(templates_dict):
return templates_dict["ds"]
- task = self.run_as_task(f, templates_dict={"ds": "{{ ds }}"})
- assert task.templates_dict == {"ds": self.ds_templated}
+ # the callable receives (and returns) the rendered templates_dict value
+ ti = self.run_as_task(f, return_ti=True, templates_dict={"ds": "{{ ds
}}"})
+ assert self._pull_xcom(ti) == self.ds_templated
Review Comment:
Why this change? The original checked if templates_dict attribute was
rendered and the new check verifies what the callable returned via xcom. I dont
think these are equivalent?
##########
devel-common/src/tests_common/test_utils/in_process_taskrun.py:
##########
@@ -0,0 +1,164 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""DB-free, xdist-safe execution of a task through a *real* supervisor socket.
+
+`run_task` (in ``pytest_plugin``) mocks supervisor comms entirely in-process
and
+has **no real socket**, so operators that spawn a subprocess which re-connects
to
+the supervisor — ``PythonVirtualenvOperator``, ``ExternalPythonOperator``,
+``run_as_user`` — fail there with ``OSError: Socket operation on non-socket``.
+
+This drives the *real* ``InProcessTestSupervisor`` (its socketpair machinery is
+created specifically for VirtualEnv operators) but injects a **dry-run
Execution-API
+client** instead of the DB-backed in-process API server, so the subprocess
gets a
+working supervisor socket without touching the metadata DB. Tests using it
need no
+``@pytest.mark.db_test`` and run under xdist.
+
+The client is the real ``Client(dry_run=True)`` (which already fakes the run
+context and no-ops heartbeats via ``noop_handler``), with the discarding
transport
+swapped for one that *remembers* XCom writes in an in-memory dict — exposed as
+``client.pushed_xcoms`` so tests can assert what a task pushed.
+
+Airflow 3+ only (``InProcessTestSupervisor`` does not exist on 2.x); callers
must
+gate on ``AIRFLOW_V_3_0_PLUS``.
+"""
+
+from __future__ import annotations
+
+import inspect
+import json
+from typing import TYPE_CHECKING, Any
+
+if TYPE_CHECKING:
+ from collections.abc import Callable
+
+ from airflow.sdk.api.client import Client
+ from airflow.sdk.execution_time.supervisor import TaskRunResult
+ from airflow.sdk.types import Operator
+
+# XCom is the only resource that must round-trip; the run-context is fed back
from the
+# (valid) ti_context the test built, and everything else (heartbeat, state
updates) is the
+# stock ``noop_handler``. (``noop_handler``'s own run-context is stale vs the
live schema.)
+_XCOM_PATH_PARTS = 5 # /xcoms/{dag_id}/{run_id}/{task_id}/{key}
+
+
+def _remembering_handler(store: dict, run_context_json: bytes) -> Callable:
+ """A dry-run transport handler: valid run-context + XCom round-trip from
``store``, else no-op."""
+ import httpx
+
+ from airflow.sdk.api.client import noop_handler
Review Comment:
Is there any issue with these being top level imports?
--
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]
