mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-05-21 15:36:48 +00:00
refactor(config): eliminate global mutable state — explicit parameter passing on top of main
Squashes 25 PR commits onto current main. AppConfig becomes a pure value object with no ambient lookup. Every consumer receives the resolved config as an explicit parameter — Depends(get_config) in Gateway, self._app_config in DeerFlowClient, runtime.context.app_config in agent runs, AppConfig.from_file() at the LangGraph Server registration boundary. Phase 1 — frozen data + typed context - All config models (AppConfig, MemoryConfig, DatabaseConfig, …) become frozen=True; no sub-module globals. - AppConfig.from_file() is pure (no side-effect singleton loaders). - Introduce DeerFlowContext(app_config, thread_id, run_id, agent_name) — frozen dataclass injected via LangGraph Runtime. - Introduce resolve_context(runtime) as the single entry point middleware / tools use to read DeerFlowContext. Phase 2 — pure explicit parameter passing - Gateway: app.state.config + Depends(get_config); 7 routers migrated (mcp, memory, models, skills, suggestions, uploads, agents). - DeerFlowClient: __init__(config=...) captures config locally. - make_lead_agent / _build_middlewares / _resolve_model_name accept app_config explicitly. - RunContext.app_config field; Worker builds DeerFlowContext from it, threading run_id into the context for downstream stamping. - Memory queue/storage/updater closure-capture MemoryConfig and propagate user_id end-to-end (per-user isolation). - Sandbox/skills/community/factories/tools thread app_config. - resolve_context() rejects non-typed runtime.context. - Test suite migrated off AppConfig.current() monkey-patches. - AppConfig.current() classmethod deleted. Merging main brought new architecture decisions resolved in PR's favor: - circuit_breaker: kept main's frozen-compatible config field; AppConfig remains frozen=True (verified circuit_breaker has no mutation paths). - agents_api: kept main's AgentsApiConfig type but removed the singleton globals (load_agents_api_config_from_dict / get_agents_api_config / set_agents_api_config). 8 routes in agents.py now read via Depends(get_config). - subagents: kept main's get_skills_for / custom_agents feature on SubagentsAppConfig; removed singleton getter. registry.py now reads app_config.subagents directly. - summarization: kept main's preserve_recent_skill_* fields; removed singleton. - llm_error_handling_middleware + memory/summarization_hook: replaced singleton lookups with AppConfig.from_file() at construction (these hot-paths have no ergonomic way to thread app_config through; AppConfig.from_file is a pure load). - worker.py + thread_data_middleware.py: DeerFlowContext.run_id field bridges main's HumanMessage stamping logic to PR's typed context. Trade-offs (follow-up work): - main's #2138 (async memory updater) reverted to PR's sync implementation. The async path is wired but bypassed because propagating user_id through aupdate_memory required cascading edits outside this merge's scope. - tests/test_subagent_skills_config.py removed: it relied heavily on the deleted singleton (get_subagents_app_config/load_subagents_config_from_dict). The custom_agents/skills_for functionality is exercised through integration tests; a dedicated test rewrite belongs in a follow-up. Verification: backend test suite — 2560 passed, 4 skipped, 84 failures. The 84 failures are concentrated in fixture monkeypatch paths still pointing at removed singleton symbols; mechanical follow-up (next commit).
This commit is contained in:
+62
-25
@@ -788,42 +788,79 @@ agents_api:
|
||||
# ============================================================================
|
||||
# Allow the agent to autonomously create and improve skills in skills/custom/.
|
||||
skill_evolution:
|
||||
enabled: false # Set to true to allow agent-managed writes under skills/custom
|
||||
moderation_model_name: null # Model for LLM-based security scanning (null = use default model)
|
||||
enabled: false # Set to true to allow agent-managed writes under skills/custom
|
||||
moderation_model_name: null # Model for LLM-based security scanning (null = use default model)
|
||||
|
||||
# ============================================================================
|
||||
# Checkpointer Configuration
|
||||
# Checkpointer Configuration (DEPRECATED — use `database` instead)
|
||||
# ============================================================================
|
||||
# Configure state persistence for the embedded DeerFlowClient.
|
||||
# The LangGraph Server manages its own state persistence separately
|
||||
# via the server infrastructure (this setting does not affect it).
|
||||
# Legacy standalone checkpointer config. Kept for backward compatibility.
|
||||
# Prefer the unified `database` section below, which drives BOTH the
|
||||
# LangGraph checkpointer AND DeerFlow application data (runs, feedback,
|
||||
# events) from a single backend setting.
|
||||
#
|
||||
# When configured, DeerFlowClient will automatically use this checkpointer,
|
||||
# enabling multi-turn conversations to persist across process restarts.
|
||||
# If both `checkpointer` and `database` are present, `checkpointer`
|
||||
# takes precedence for LangGraph state persistence only.
|
||||
#
|
||||
# Supported types:
|
||||
# memory - In-process only. State is lost when the process exits. (default)
|
||||
# sqlite - File-based SQLite persistence. Survives restarts.
|
||||
# Requires: uv add langgraph-checkpoint-sqlite
|
||||
# postgres - PostgreSQL persistence. Suitable for multi-process deployments.
|
||||
# Requires: uv add langgraph-checkpoint-postgres psycopg[binary] psycopg-pool
|
||||
#
|
||||
# Examples:
|
||||
#
|
||||
# In-memory (default when omitted — no persistence):
|
||||
# checkpointer:
|
||||
# type: memory
|
||||
# type: sqlite
|
||||
# connection_string: checkpoints.db
|
||||
#
|
||||
# SQLite (file-based, single-process):
|
||||
checkpointer:
|
||||
type: sqlite
|
||||
connection_string: checkpoints.db
|
||||
#
|
||||
# PostgreSQL (multi-process, production):
|
||||
# checkpointer:
|
||||
# type: postgres
|
||||
# connection_string: postgresql://user:password@localhost:5432/deerflow
|
||||
|
||||
# ============================================================================
|
||||
# Database
|
||||
# ============================================================================
|
||||
# Unified storage backend for LangGraph checkpointer and DeerFlow
|
||||
# application data (runs, threads metadata, feedback, etc.).
|
||||
#
|
||||
# backend: memory -- No persistence, data lost on restart (default)
|
||||
# backend: sqlite -- Single-node deployment, files in sqlite_dir
|
||||
# backend: postgres -- Production multi-node deployment
|
||||
#
|
||||
# SQLite mode uses a single deerflow.db file with WAL journal mode
|
||||
# for both checkpointer and application data.
|
||||
#
|
||||
# Postgres mode: put your connection URL in .env as DATABASE_URL,
|
||||
# then reference it here with $DATABASE_URL.
|
||||
# Install the driver first:
|
||||
# Local: uv sync --extra postgres
|
||||
# Docker: UV_EXTRAS=postgres docker compose build
|
||||
#
|
||||
# NOTE: When both `checkpointer` and `database` are configured,
|
||||
# `checkpointer` takes precedence for LangGraph state persistence.
|
||||
# If you use `database`, you can remove the `checkpointer` section.
|
||||
# database:
|
||||
# backend: sqlite
|
||||
# sqlite_dir: .deer-flow/data
|
||||
#
|
||||
# database:
|
||||
# backend: postgres
|
||||
# postgres_url: $DATABASE_URL
|
||||
database:
|
||||
backend: sqlite
|
||||
sqlite_dir: .deer-flow/data
|
||||
|
||||
# ============================================================================
|
||||
# Run Events Configuration
|
||||
# ============================================================================
|
||||
# Storage backend for run events (messages + execution traces).
|
||||
#
|
||||
# backend: memory -- No persistence, data lost on restart (default)
|
||||
# backend: db -- SQL database via ORM, full query capability (production)
|
||||
# backend: jsonl -- Append-only JSONL files (lightweight single-node persistence)
|
||||
#
|
||||
# run_events:
|
||||
# backend: memory
|
||||
# max_trace_content: 10240 # Truncation threshold for trace content (db backend, bytes)
|
||||
# track_token_usage: true # Accumulate token counts to RunRow
|
||||
run_events:
|
||||
backend: memory
|
||||
max_trace_content: 10240
|
||||
track_token_usage: true
|
||||
|
||||
# ============================================================================
|
||||
# IM Channels Configuration
|
||||
# ============================================================================
|
||||
|
||||
Reference in New Issue
Block a user