FanouZeng-TT eb7c342fb1
fix(sandbox): measure warm-pool idle age on a monotonic clock (#7035)
* fix(sandbox): measure warm-pool idle age on a monotonic clock

Warm-pool expiry measures a duration, but every provider stamped and reaped
entries using the wall clock. A forward correction could therefore destroy
fresh sandboxes, while a backward correction could retain expired ones until
the clock caught up.

Move every warm-pool writer and reader to time.monotonic(), including the
Tenki and OpenSandbox reset paths missed by the earlier closed attempt. Keep
absolute SandboxInfo.created_at and reconciliation grace timestamps on the
wall clock. Convert AIO's sibling active-idle timestamps as one clock domain,
and update finite clock mocks for the additional duration read.

Fixes #6970

* test(sandbox): keep active-idle race fixtures in the monotonic domain

The production AIO activity clock moved to monotonic time, but the shared
orphan-reconciliation helper still stamped active fixtures with wall time.
CI then computed a negative idle age, so two teardown race tests never reached
the ownership gate. Use the same monotonic domain as production.

* test(sandbox): read warm-pool idle fixtures on the monotonic clock

The idle-age conversion left several fixtures seeding the fields the reaper
now reads with values from the clock it no longer reads:

- `test_idle_reaping_forces_a_new_remote` froze `warm_pool_lifecycle.time.time`,
  so the benchmark's reaper compared against real elapsed monotonic seconds —
  zero over the test's lifetime. Nothing expired, the entry survived, and the
  second turn came back as a warm hit.
- Three orphan-reconciliation fixtures seeded `_last_activity` with `0.0` and
  two aio fixtures with `time.time()`, both of which are far below a running
  monotonic clock: the computed idle age went negative, so the reaper never
  reached the ownership claim these tests are built to exercise.

Seed them from `time.monotonic()` instead, and keep `created_at` (a wall-clock
field) on `time.time()`.
2026-10-20 19:36:04 +08:00
..

BoxLite backend

Runs each DeerFlow sandbox as a BoxLite micro-VM — a daemonless, OCI-native VM with its own kernel (libkrun/KVM on Linux, Hypervisor.framework on macOS). Motivated by the resource/cold-start pain with the default AIO Docker sandbox in #3439 and #3213; discussion in #3936.

Configuration

sandbox:
  use: deerflow.community.boxlite:BoxliteProvider
  image: python:3.12-slim         # any OCI image (default: python:3.12-slim)
  memory_mib: 1024                # per-box memory cap (optional)
  cpus: 2                         # per-box vCPUs (optional)
  replicas: 3                     # active + warm VM cap per gateway process (default: 3)
  idle_timeout: 600               # warm VM idle seconds before stop; 0 disables
  health_check_skip_seconds: 0.0  # optional low-latency mode: skip reclaim
                                  #   health checks for recent releases; 0 keeps
                                  #   reliability-first validation (default: 0.0)
  environment:                    # injected into every command
    PYTHONUNBUFFERED: "1"

Install the optional runtime before selecting this provider:

pip install "deerflow-harness[boxlite]"

The boxlite package is an optional DeerFlow harness extra, not part of the default install. It is also limited to the host platforms and architectures where BoxLite publishes wheels and can boot micro-VMs. Unsupported development hosts, such as Windows, should use another sandbox provider or run DeerFlow from a supported Linux/macOS environment.

Host requirement: BoxLite boots micro-VMs, so a Linux host needs KVM — i.e. nested virtualization when DeerFlow runs inside a cloud VM. macOS uses Hypervisor.framework. This is the main deployment constraint to weigh vs. the container-based providers.

Design

DeerFlow's Sandbox contract is synchronous; BoxLite's SDK is async-native and its box handles are event-loop-affine. The provider owns one private asyncio loop on a daemon thread and marshals every coroutine onto it via run_coroutine_threadsafe. BoxLite boxes are named deterministically from user_id:thread_id, released into an in-process warm pool after each agent turn, and reclaimed by the same thread on the next acquire.

File Role
provider.py SandboxProvider lifecycle + the private-loop bridge
box.py Sandbox adapter; execute_command + file ops

Contract coverage

The full Sandbox surface is implemented. File operations run as shell commands inside the box and reuse deerflow.sandbox.search, mirroring e2b_sandbox:

  • execute_command — sh -lc, with per-call env and timeout.
  • read_file / write_file / update_file — cat and chunked base64 (binary-safe, no arg-size limit).
  • download_file — 100 MB cap, restricted to the /mnt/user-data prefix.
  • list_dir / glob / grep — find / grep with busybox-portable flags; results filtered/capped in Python.

Command timeouts pass the same deadline to the SDK and event-loop bridge. A bridge deadline returns Error: command timed out followed by Exit Code: 124. BoxLite's SimpleBox.exec converts SDK wait failures to ExecResult(exit_code=-1); if that result arrives before the bridge deadline, DeerFlow preserves -1. The bridge handler catches Python's builtin TimeoutError, which is distinct from the SDK's boxlite.TimeoutError.

The provider creates /mnt/user-data/{workspace,uploads,outputs} and /mnt/skills on box start so those virtual paths resolve natively.

Warm-pool capacity is governed by sandbox.replicas across active + warm VMs. sandbox.idle_timeout controls how long released warm VMs stay running; 0 disables idle reaping. Active boxes are never evicted to satisfy the cap.

Status

Verified end-to-end against a live box (provider resolution → execute_command → file ops) on macOS/HVF. Linux/KVM validation and benchmarks vs. the AIO sandbox are tracked in #3936.