mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-08-08 05:48:53 +00:00
1f792d0f4b
* feat(extensions): add middleware plugin foundation * fix(extensions): stop config resolution from masking extension loading `create_app()` resolved the configured plugin list inside the fail-open guard around `load_extensions()`. CI has no `config.yaml` (gitignored and never generated by the workflow), so `get_app_config()` raised `FileNotFoundError` there and was swallowed as an extension failure -- `load_extensions()` never ran at all, and the four `create_app()` tests in `test_extension_app_loading.py` passed locally but failed on every runner. Resolve the plugin list before the guard. Only an absent `config.yaml` is tolerated, mirroring `_resolve_trace_enabled_for_app_construction()`: `create_app()` runs at import time, and lifespan still performs strict config loading before serving. A `config.yaml` that exists but fails to parse or validate now propagates instead of being reported as an extension failure -- reporting it as the latter silently dropped a `required: true` extension rather than failing the boot. Make the tests config-independent with an autouse `stub_app_config` fixture, following the existing pattern in `test_gateway_lifespan_shutdown.py`, and cover both new branches of the config-resolution boundary. * fix(extensions): bind the run's extension snapshot through subagent delegation The lead-agent path resolves one immutable loaded-extension snapshot per run and binds it through task-store allocation and graph construction, but the subagent path re-read the process-wide singleton at execution time. In production both are the same object, yet a `set_loaded_extensions()` between the lead run's start and a subagent's execution (test teardown, a future hot-reload path) would let one run mix two extension generations — exactly what the documented invariant exists to prevent. The graph-build binding is a ContextVar scoped to synchronous construction, so it has already exited by the time a tool delegates; the snapshot has to travel through runtime context instead. The run worker publishes it under the host-internal `EXTENSION_SNAPSHOT_CONTEXT_KEY` (written after the caller merge, popped when the run has none, so a caller-supplied value is never authoritative), `task_tool` reads it back through the type-checking `resolve_run_extensions()`, and `SubagentExecutor` binds it at construction. Callers outside the Gateway run path — embedded `DeerFlowClient`, standalone LangGraph Server — install no snapshot and keep the existing `get_loaded_extensions()` fallback. * refactor(extensions): defer the ordering table by call, not by a lying tuple `CORE_ORDERING_CONSTRAINTS` was a `tuple` subclass that overrode only `__iter__` and resolved into a class-level `_resolved` side channel. A tuple cannot populate its own storage after construction, so the instance stayed the empty tuple it was built as: `len()` was 0, `bool()` was False, `in` was always False, indexing raised, slicing and `reversed()` came back empty, and it compared unequal to the plain tuples tests substitute for it — all while iteration yielded the real constraints. Only `assert_ordering` consumed it, and only by iterating, so the split went unnoticed. The sibling `_AnchorTable(dict)` uses the same idea soundly because dict is mutable: `self.update()` fills the real storage, making every inherited operation correct. That trick does not survive the port to an immutable type. Replace it with `core_ordering_constraints()`, matching how `stack.py` defers the same kind of table via `_anchors()`. The deferral is kept — it is about dependency direction, not just cycles: `extensions/` is the layer the middleware layer calls into, so a module-scope `agents.middlewares` import here points the dependency backwards and closes a cycle as soon as any middleware imports something under `extensions/` at module level. Resolution stays at `assert_ordering` time, which already runs inside the middleware builder. Tests pin both halves: the returned value is a plain tuple whose len/bool/ membership/indexing/reversal/equality agree with iteration, and a subprocess probe asserts importing `extensions.ordering` does not load the middleware layer while calling the function does.
85 lines
3.1 KiB
TOML
85 lines
3.1 KiB
TOML
[project]
|
|
name = "deer-flow"
|
|
version = "2.1.0"
|
|
description = "LangGraph-based AI agent system with sandbox execution capabilities"
|
|
readme = "README.md"
|
|
requires-python = ">=3.12"
|
|
dependencies = [
|
|
"deerflow-harness",
|
|
"fastapi>=0.115.0",
|
|
"httpx>=0.28.0",
|
|
"python-multipart>=0.0.31",
|
|
"sse-starlette>=2.1.0",
|
|
"uvicorn[standard]>=0.34.0",
|
|
"lark-oapi>=1.4.0",
|
|
"slack-sdk>=3.33.0",
|
|
"python-telegram-bot>=21.0",
|
|
"langgraph-sdk>=0.1.51",
|
|
"markdown-to-mrkdwn>=0.3.1",
|
|
"wecom-aibot-python-sdk>=0.1.6",
|
|
"dingtalk-stream>=0.24.3",
|
|
"bcrypt>=4.0.0",
|
|
"pyjwt>=2.13.0",
|
|
"email-validator>=2.0.0",
|
|
"e2b-code-interpreter>=2.8.1",
|
|
]
|
|
|
|
[project.optional-dependencies]
|
|
postgres = ["deerflow-harness[postgres]"]
|
|
redis = ["deerflow-harness[redis]"]
|
|
discord = ["discord.py>=2.7.0"]
|
|
monocle = ["deerflow-harness[monocle]"]
|
|
browser = ["deerflow-harness[browser]"]
|
|
memory-zh = ["deerflow-harness[memory-zh]"]
|
|
|
|
[dependency-groups]
|
|
dev = [
|
|
"blockbuster>=1.5.26,<1.6",
|
|
"hypothesis>=6.100,<7",
|
|
"jsonschema>=4.26.0",
|
|
"prompt-toolkit>=3.0.0",
|
|
"pytest>=9.0.3",
|
|
"pytest-asyncio>=1.3.0",
|
|
"ruff>=0.14.11",
|
|
# Monocle tracer (also the deerflow-harness[monocle] extra); kept in the dev
|
|
# group so the tracing tests can import it without forcing it onto installs.
|
|
"monocle_apptrace>=0.8.8",
|
|
# redis is an optional runtime extra (deerflow-harness[redis]); pin it in the
|
|
# dev group so the stream-bridge tests can always import/exercise the redis
|
|
# bridge without forcing it onto production installs.
|
|
"redis>=5.0.0",
|
|
# TUI runtime dep (also declared as the deerflow-harness[tui] extra); kept in
|
|
# the dev group so the terminal workbench can be run and tested locally / in CI.
|
|
"textual>=0.80",
|
|
]
|
|
|
|
[tool.pytest.ini_options]
|
|
markers = [
|
|
"no_auto_user: disable the conftest autouse contextvar fixture for this test",
|
|
"allow_blocking_io: opt out of the strict Blockbuster gate in tests/blocking_io/",
|
|
"integration: tests that require an external service (e.g. Redis); skipped when unavailable",
|
|
"live: tests that call real external APIs and require explicit opt-in",
|
|
]
|
|
|
|
[tool.uv]
|
|
index-url = "https://pypi.org/simple"
|
|
# langgraph-sdk 0.4.2 (pulled in by langgraph 1.2.9 for DeltaChannel) pins
|
|
# `websockets<16,>=14`, silently downgrading websockets 16.0 -> 15.0.1. The
|
|
# pin is not grounded in any API incompatibility: websockets 16's only
|
|
# breaking change is requiring Python >=3.10 (we require >=3.12), the sdk
|
|
# only imports `websockets.asyncio.client`/`websockets.exceptions` (both
|
|
# 16-compatible), and DeerFlow never uses the sdk's WebSocket transport
|
|
# (httpx/SSE only). Pin the exact pre-upgrade 16.0 for the IM channel
|
|
# integrations (dingtalk-stream, python-telegram-bot, etc.) that ran on it
|
|
# before. Remove once langgraph-sdk relaxes the pin upstream. Note: enabling
|
|
# the `openai[realtime]` or `slack-sdk[optional]` extras would conflict (they
|
|
# also cap websockets<16).
|
|
override-dependencies = ["websockets==16.0"]
|
|
|
|
[tool.uv.workspace]
|
|
members = ["packages/harness", "packages/extension-api"]
|
|
|
|
[tool.uv.sources]
|
|
deerflow-harness = { workspace = true }
|
|
deerflow-extension-api = { workspace = true }
|