734 Commits

Author	SHA1	Message	Date
sjr666666	f4d4f776f6	fix(skills): record the content actually overwritten in custom-skill history (#6153) ... * fix(skills): record the content actually overwritten in custom-skill history Scope: - backend/app/gateway/routers/skills.py: move the prev_content read of update_custom_skill and the current-content read of rollback_custom_skill into their drained persist tails (read -> write -> append_history in one worker thread, no awaits in between). The blocked-rollback branch now builds its informational entry separately. No behavior contract changes: status codes, cancellation draining, and prompt-cache refresh order are untouched. - backend/tests/test_skills_custom_router.py: two regression tests that inject a concurrent write during the scan phase and assert the history entry's prev_content equals the revision actually overwritten on disk. Why: prev_content was read before the security scans, so a concurrent revision landing between that read and the persisted write was overwritten on disk but absent from the history chain, making it unreachable by a later rollback and desynchronizing the audit record. Tests: uv run pytest tests/test_skills_custom_router.py --basetemp=... -> 36/36 passed (34 existing + 2 new); ruff check and ruff format --check clean on both files. Python 3.12.13, Windows 11. * fix(skills): serialize custom-skill mutations and pin the concurrency regression to the real window - Add a module-level mutation lock shared by the edit, delete, and rollback paths, covering the full read -> write -> history-append sequence so a concurrent PUT cannot land between a request's predecessor read and its write (previously the projection lock started inside write_custom_skill, leaving that window open). - Replace the two regression tests: they now pause the first mutation inside its storage write after the predecessor read (deterministic gate), complete a second real HTTP PUT inside that window, and assert the history chain stays replayable. Verified both tests fail against the base implementation (2 failed) and pass with the lock (2 passed); full file 36 passed, ruff check + format clean. * fix(skills): scope the custom-skill mutation lock to the owning user The lock serializing the read -> write -> append sequence was one process-wide lock, and that sequence wraps write_custom_skill's entire user projection rebuild. A user waiting on their own projection lock, or copying a large or slow linked package, therefore stalled every other user's edit, rollback, and delete of unrelated custom skills, even though their skill trees, histories, and projection roots are disjoint. The base storage only serialized those mutations per user projection. Key the lock on the canonical owning-user storage root instead, so one user's mutations remain a single critical section — including across separately constructed storage objects, which a hot-reloaded config or a later request creates — while two users never share it. The read -> write -> append sequence still cannot interleave within a user, and the lock is still acquired and released inside the worker thread's own with block, so caller cancellation cannot strand it. * fix(skills): serialize custom history across gateway processes --------- Co-authored-by: sjr666666 <sjr666666@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-10 10:32:31 +08:00
Storm	061a7dfc14	feat(channels): select the model per conversation via /model (#6534) ... * feat(channels): select the model per conversation via /model IM channels could list models with /models but had no way to choose one: the model for a conversation came only from channel/session config or the server default, so a user who needed a stronger or cheaper model for one task had to reconfigure the whole channel or move to the web UI. - /model <name> pins a model to the current conversation, validated against the caller-visible /api/models list (list membership doubles as the authorization check), persisted in thread metadata so it survives a Gateway restart and applies from the next message in place — unlike /agent use, which must start a new conversation. - The pin is written to all three runtime carriers (run context, configurable, context) after the session layers merge, so it wins over channel/session configured models; like any explicitly requested model it also takes precedence over a Custom Agent's configured model. - /model (no args) reports the effective model and its source through one resolver that mirrors the run merge order (default -> channel -> user, context carrier over configurable, both session-config carriers scanned); /model default clears the pin; /models names the pinned model in a footer. - Pin lookups degrade instead of failing messages: the status query reports "Current model: unknown" on a lookup failure (matching the /models footer), and the reuse-thread preload leaves the in-process cache untouched so the next turn retries a transient threads.get. - Reserve "model" in the slash-skill reserved-name contract (backend, contract fixture, frontend), register the Telegram handler, and document the command in /help, README, and README_zh. * fix(channels): fence model pin cache and mirror runtime model resolution Review follow-up for /model: - Serialize cold pin loads with persist+cache publication under a per-manager lock, so a slow threads.get that captured pre-pin metadata can never overwrite a concurrently committed selection (commands are not run-serialized). - _resolve_configured_model_name now replicates the run path's shallow session merges and applies the real runtime precedence — config.context (preserved by build_run_config, unbeatable by the setdefault-filled body context) > top-level context > configurable — instead of scanning per-layer carriers; a later layer replacing a nested carrier wholesale no longer leaks a stale value into the status reply. - /api/models resolves the trusted bound owner for internal channel calls and filters the list with the owner's role, so /model selection gates on the same principal that run admission admits for that account. Tests: pin-write-vs-in-flight-load race, status compared against the real merged runtime config (parametrized across carriers), nested-carrier replacement, and owner-role filtering with the real RBAC provider; each verified red by reverting exactly its guard. * fix(channels): share model resolvers with the run path and harden the pin lifecycle The /model status reply re-implemented the session-layer merge and the Gateway carrier precedence, and it ignored the custom-agent model fallback — on a thread pinned to a custom agent whose config sets ``model:`` it reported "server default" while the run actually used the agent's model. Review also found the pin lock spanned a network call and a stale pin bricked its conversation behind the generic error fallback. - Extract ``_select_carried_model_name`` as the single carrier-precedence rule; the status reply reuses the run path's exact ``_merge_dicts`` layer shapes, so a future layering change has one place to touch. - Extract ``_resolve_message_assistant_id`` / ``_resolve_assistant_id`` and share the assistant precedence chain between the run path and the status reply. - Fall back to the resolved custom agent's configured ``model`` when no session layer carries one, mirroring the agent factory's ``_resolve_model_name(requested or agent_model_name)``; the reply now distinguishes "(from channel configuration)" and "(from agent configuration)". - Run the cold ``threads.get`` in ``_load_thread_model`` outside ``_model_pin_lock``; only cache publication takes the lock, with a post-GET re-check so an in-flight /model write still wins over the older snapshot. - Detect the run-admission allowlist rejection in ``_handle_message`` and recover: clear the stale pin (durable write plus cache under the lock) and reply with the reset and the /model recovery instead of the generic internal-error fallback. - Document /model and the ``channel_model_name`` pin semantics in backend/app/channels/AGENTS.md. * fix(channels): fence stale-pin recovery and cover streaming admission failures Review round 4 found the stale-pin recovery itself unsafe and incomplete: - Recovery cleared whatever pin was current when the delayed admission rejection arrived, so a rejection for an old pin could erase a replacement selection committed mid-flight (and tell the user the new model was unavailable). ``_stale_pin_recovery`` now takes the failed run's own selection (``expected_pin``, read from its run context) and clears only while that selection is still current under the lock; a replaced or already-reset selection gets a non-destructive reply instead. - Feishu/Telegram/DingTalk streaming turns never reached the recovery hook because ``_handle_streaming_chat`` swallows start_run's 400 into its terminal-error reply. The recovery now runs in the streaming terminal-error path too, delivered as the single final outbound with the same dedupe cleanup; blocking, streaming, and fire-and-forget run-creation paths all handle the rejection at the site that knows the submitted selection. * docs(channels): fit the /model entry within the agent-guidance size budget The base file sits one byte under the AGENTS.md hard limit, so documenting /model requires net-zero growth: keep the command-inventory addition and a compact pin-semantics sentence, and losslessly tighten the surrounding prose (the file was already at the limit). * fix(channels): apply the review suggestions on /model replies Three non-blocking findings from the latest review: - The /models pin footer decorated the failure string too, advertising a pin next to an error that lists nothing. The command now fetches the listing through ``_fetch_gateway_json`` and appends the footer only on a successful fetch. - The /model status reply labeled every session-layer model "from channel configuration", misreporting user- and default-layer models. The label is now "session configuration" for every session layer. - Stale-pin recovery replies read as if the turn went through, but the run was rejected before starting and the triggering message never reached the agent. All recovery variants now end with an explicit "Your message was not processed — please send it again." * fix(channels): recover stale model pins on the follow-up drain path The drain is the fourth run-creation path and the only one without stale-pin recovery: a /model pin that left the allowlist while follow-ups were buffered made every drained runs.create fail admission, requeueing the batch into the same 400 on every cycle with no user-facing recovery — contradicting the documented "stale pins self-clear" invariant. - Compute expected_pin from the drain's run context (mirroring _handle_chat_on_thread, initialized None since _resolve_run_params is itself inside the guarded try) and run _stale_pin_recovery on drain failure before requeueing; the pin self-clears and the requeued batch succeeds on the next cycle. - Pass the caller-authoritative thread_id into _stale_pin_recovery: every call site already holds it, so recovery never re-derives it from the message — a store-mapping rewrite between dispatch and recovery can never clear the wrong conversation's pin, and the lookup's failure mode (and its guard) disappears entirely. - Return StalePinRecovery(text, resolved) so requeueing callers can tell a cleared pin from a repeat failure: the drain logs INFO when the next cycle is free of this rejection and WARNING when recovery could not remove it (persist failed, or the selection came from session configuration, which still carries it) — no silent infinite requeue loop. Drain logs carry structured facts only: the reply text ends with a "please resend" note that would double-process buffered messages retried automatically (GitHub, the only buffering channel, sends log-only anyway). - Reword the config-carried recovery reply: with no pin held, the rejected selection came from session configuration — name that source and the fix instead of claiming a default takeover that would not happen. - Correct the _load_thread_model lock docstring (writes deliberately hold _model_pin_lock across threads.update) and read the agent config for /model status off the event loop via asyncio.to_thread, with a Blockbuster-gated blocking_io regression test. - Pin the under-lock re-check in _stale_pin_recovery with a concurrency test (a /model committed during the lock-wait window wins; recovery persists nothing), mutation-verified — the drain is the only caller running on a background task without the serialized-run lock, so it is the path most exposed to that window. * Revert "fix(channels): recover stale model pins on the follow-up drain path" This reverts commit 0b4652c689afb56791e5e670901c97a4bf44a156. The drain recovery work moves to a dedicated PR stacked on this branch, keeping #6534 scoped to the /model feature itself. * fix(channels): recover stale model pins on the follow-up drain path The drain is the fourth run-creation path and the only one without stale-pin recovery: a /model pin that left the allowlist while follow-ups were buffered made every drained runs.create fail admission, requeueing the batch into the same 400 on every cycle with no user-facing recovery — contradicting the documented "stale pins self-clear" invariant. - Compute expected_pin from the drain's run context (mirroring _handle_chat_on_thread, initialized None since _resolve_run_params is itself inside the guarded try) and run _stale_pin_recovery on drain failure before requeueing; the pin self-clears and the requeued batch succeeds on the next cycle. - Pass the caller-authoritative thread_id into _stale_pin_recovery: every call site already holds it, so recovery never re-derives it from the message — a store-mapping rewrite between dispatch and recovery can never clear the wrong conversation's pin, and the lookup's failure mode (and its guard) disappears entirely. - Return StalePinRecovery(text, resolved) so requeueing callers can tell a cleared pin from a repeat failure: the drain logs INFO when the next cycle is free of this rejection and WARNING when recovery could not remove it (persist failed, or the selection came from session configuration, which still carries it) — no silent infinite requeue loop. Drain logs carry structured facts only: the reply text ends with a "please resend" note that would double-process buffered messages retried automatically (GitHub, the only buffering channel, sends log-only anyway). - Reword the config-carried recovery reply: with no pin held, the rejected selection came from session configuration — name that source and the fix instead of claiming a default takeover that would not happen. - Correct the _load_thread_model lock docstring (writes deliberately hold _model_pin_lock across threads.update) and read the agent config for /model status off the event loop via asyncio.to_thread, with a Blockbuster-gated blocking_io regression test. - Pin the under-lock re-check in _stale_pin_recovery with a concurrency test (a /model committed during the lock-wait window wins; recovery persists nothing), mutation-verified — the drain is the only caller running on a background task without the serialized-run lock, so it is the path most exposed to that window. (cherry picked from commit 0b4652c689afb56791e5e670901c97a4bf44a156) * fix(channels): apply the third review round on /model command replies - Delete the dead kind == "models" branch in _fetch_gateway: /models has rendered the listing inline since the pin-footer fix, so the helper's copy was unreachable and had already diverged (unguarded m["name"], no pin footer). The internal-auth-header test now drives the surviving /memory kind. - Guard the inline /models listing comprehension like the _handle_model_command sibling (isinstance(m, Mapping) and isinstance(m.get("name"), str)), so a malformed payload entry can no longer turn the command into the generic internal-error reply; regression: test_models_command_skips_malformed_entries. - Drop the unused user parameter from _resolve_bound_owner_for_model_list: the resolved owner comes solely from the trusted header, and the parameter implied the caller's own principal shaped the filter. * fix(channels): apply the fourth review round on the /model lifecycle - Preserve fresh model pins across cache eviction: a cold threads.get racing a successful /model write could still publish its stale snapshot after clear-on-pressure evicted the fresh entry — the in-cache re-check cannot see an eviction. The model-pin cache now carries a write generation; a load whose generation moved during the GET refetches once instead of publishing over the committed selection. Regression: test_fresh_model_pin_survives_cache_eviction_during_cold_load (blocked GET, write, eviction, then the refetch wins), mutation-verified. - Resolve context-carried agents before reporting their model: /model status now mirrors the run path's effective-agent rule — explicit message/thread choice overwrites every carrier, then the merged carriers' agent_name (new _select_carried_agent_name, sharing the model-name precedence via _select_carried_value), then the session-layer assistant_id that only setdefaults into context. A session with context.agent_name=coder now reports coder-model instead of server default, and assistant_id=writer alongside context.agent_name=coder reports coder-model instead of writer-model. Regressions: context-carried, context-beats-assistant_id, and thread-pin-beats-context status tests. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-10 09:45:17 +08:00
ZJPex	4cb8e3096b	feat(mcp): filter background tasks by status (#6527) ... * feat(mcp): filter background tasks by status * feat(mcp): expose task list filters in Gateway * docs(mcp): describe background task query filters --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-10 08:53:51 +08:00
Storm	b9a75b869d	fix(sandbox): attest lark broker mode per Pod and quarantine uncertain shell outcomes (#6436) ... * fix(sandbox): attest lark broker mode per Pod and quarantine uncertain shell outcomes Why this change: Two fail-open paths in the AIO sandbox lifecycle. First, the lark broker capability probe collapsed "provisioner unreachable" into "broker not configured": one 1.5s timeout cached a negative for 300s, so new sandboxes were created without the broker sidecar while the per-user credential directories were still bind-mounted into the container, and existing Pods kept being reused without their actual mode ever being read. Second, an implicit-shell command that timed out or returned an unknown status only marked the current client object; warm-pool reclaim and rediscovery built a fresh client that re-entered a container whose shell state could not be proven clean, and nothing about that ambiguity survived a Gateway restart. What changed: - The capability cache stores confirmed observations only, keyed per provisioner endpoint/auth identity; an unknown answer (timeout, malformed payload) raises instead of selecting credential placement, while a confirmed broker requirement is retained through outages. One in-flight probe per identity shares success and failure, and a Pod-attested mode contradicting the cache forces one shared refresh. - Execution uses the mode attested for the actual sandbox: SandboxInfo.lark_cli_broker flows from the provisioner's atomic Pod observation into the client, so a probe outage delays drift detection but never denies reuse of an attested runtime, and never trusts an unattested one. - The provisioner reports each Pod's actual broker mode, generation (Pod UID) and shell capacity from one read, rejects lark requests conflicting with its configuration (409/503 carrying a capability-refresh marker the Gateway uses to drop the stale cache entry), rejects conflicting or Terminating Pods on coordination creates while reporting Terminating as data to status/get/list, and answers Pod presence independently of Service readiness. - A persistent quarantine (DEER_FLOW_HOME/sandbox-quarantine, keyed by scope/sandbox/generation) fences containers after uncertain implicit shell outcomes across client rebuilds and restarts; in-process reuse, warm reclaim, discovery, create responses and orphan reconciliation all pass one policy gate, and replacement runs under the existing ownership and teardown fences. A fenced sandbox still tracked after a failed release-recycle is destroyed inline on the next acquire. - Quarantine records retire only after confirmed absence, retrying partial cleanup for the quarantined generation and releasing remembered ports under the same fences; local stop failures now propagate instead of being logged away, and remote destroy errors surface to callers. Problem solved: A provisioner blip could silently strip broker isolation from new lark sandboxes for minutes at a time, and ambiguous shell outcomes let corrupted default shells persist across warm reuse, rediscovery and restarts. Docs updated: README, aio_sandbox and skills AGENTS.md. * docs(changelog): record sandbox attestation and quarantine fix (#6436) * fix(sandbox): preserve active leases and fail closed on unattested broker modes Concurrent uploads could recycle a healthy AIO runtime while another holder was creating or cleaning up a command session. Older provisioner responses could also trigger destructive replacement before failing admission. - Distinguish pending session creation from ambiguous outcomes and reserve idle teardown until execution and upload holders finish scope cleanup. - Reject stale fork lookups and reconcile cancelled acquires without releasing a sandbox still borrowed by another holder. - Default Lark broker mode to unverified and preserve unattested Pods until the provisioner is upgraded. - Recognize Docker 29 absence diagnostics while matching resource names exactly. - Preserve Gateway upload errors and cover admission and lifecycle regressions. * fix(sandbox): scope the unverified-broker refuse path to attested providers The fail-closed raise in _lark_cli_env_from_runtime treated every Sandbox without a lark_cli_broker attribute as unverified, but only AioSandbox carries the attestation — E2B, OpenSandbox, Tenki, and Boxlite have no broker sidecar, no credential mounts, and no provisioner to upgrade, so every lark-cli command on those providers failed with an unactionable error. Declare the tri-state on the Sandbox base class (defaulting to False, the only mode brokerless providers have) so the None fail-closed path stays scoped to AioSandbox's deliberate unverified default. - Add lark_cli_broker: bool | None = False to the Sandbox ABC, mirroring the persistent_shell_sessions tri-state pattern - Add a regression test pinning the non-broker overlay for a provider without the attribute * fix(sandbox): close review gaps in broker attestation and teardown lifecycle Address the latest #6436 review round: - The provisioner's post-build broker-mode 409 now carries the capability-refresh marker, so an incompatible-mode conflict surfaced by idempotent re-create, attestation drift or post-create verification drops the Gateway's cached capability observation instead of repeating the same 409 for the full negative-cache TTL. - AioSandboxProvider.destroy() returns the _destroy_tracked outcome: False when teardown is deferred because an execution/upload holder or a peer teardown is still active, so callers can no longer mistake a deferred destroy for a completed one. - A live replacement under the same logical ID proves the fenced old generations are absent; retire_replaced_generations prunes only those stale records so they cannot strand future creates, while the live generation's fence and unversioned crash fences are never touched. - SandboxInfo.from_dict keeps a missing lark_cli_broker attestation unverified (None) instead of silently rehydrating as attested non-broker. - The restricted-network inspect path shares the strict _is_no_such_network_error parser, closing the substring loophole for context-name collisions and wrong-target errors. * docs(sandbox): condense lease notes to keep the AGENTS.md chain under the size gate The three lease notes added in 26c307f3 pushed the effective guidance chain to 98,312 bytes — 8 over the 98,304 hard limit enforced by agent-guidance (AG002). Fold them into two lines carrying the same rules. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-10 07:56:09 +08:00
NanPan	479067ea8c	fix(channels): fence manager startup across completed shutdown (#6521) ... * fix(channels): fence service startup after concurrent shutdown * test(channels): pin delayed manager startup after stop * fix(channels): avoid duplicate manager drain during shutdown * test(channels): name regression for shutdown generation * test(channels): remove ambiguous epoch-named regression * fix(channels): drain late manager start during in-flight shutdown * test(channels): cover manager startup during in-flight channel drain * fix(channels): serialize startup and stale cleanup --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-10 07:43:05 +08:00
Zeren Wang	553f85e788	feat(projects): best-effort LLM summaries for shelf documents (#6581) ... Opt-in per-document summary column rendered into the injected <documents> index, list_project_documents JSON, and the documents API. Pipeline (projects/summaries.py, behind the narrow enqueue_summary interface): - The two shelf write routes enqueue a job on created=True; dedup hits never regenerate. Off by default (projects.summaries_enabled). - Bounded worker pool (summary_concurrency + bounded summary_queue_size; a full queue drops the job) fed by FIFO; shutdown drains queued jobs, delivers one sentinel per worker via blocking put (queue smaller than the worker pool cannot strand idle workers), and bounds only genuinely in-flight jobs with the grace period. - Jobs carry (document_id, project_id, user_id) explicitly; the job's owner is bound into the user ContextVar around the model call so tracing/usage attribution never falls back to 'default'. - Text source reuses read_text_serving_path (convertible-first rule, content validation); conversion has no deadline (await_drained), the model call has a caller-side wait limit — the worker slot is retained until the provider call actually finishes and late results are discarded. - Output contract: strip leading <think> reasoning -> unwrap fence/ quotes -> collapse to one line -> empty is NULL -> UTF-8 byte cap on a character boundary; length-capped responses (provider-normalized detectors) are failures. - set_summary pins updated_at (literal self-assignment) so a landing summary never reorders the shelf; owner-predicated UPDATE is a no-op on rows purged mid-generation. - Metrics: eligible/success/failed/skipped/queue_dropped/ uncapped_accepted. Schema/config: - project_documents.summary (migration 0036, nullable, no backfill; forward-compat floor unchanged). - Six projects.summary_* keys, all registered in STARTUP_ONLY_FIELDS (captured once at lifespan startup); config_version 57 -> 58. - run_oneshot_llm gains an optional model_overrides passthrough (passed only when set, existing callers unchanged) and a detailed variant exposing the raw response message for termination-signal detection. Docs: API.md response field, ARCHITECTURE.md pipeline paragraph, migrations AGENTS.md chain head, root AGENTS.md records the scoped all-core exception with the lift-out path.	2026-10-10 07:11:02 +08:00
Totoro	0fe6e63a68	feat(goal): show why a chat goal stopped and when it was met, and redact the goal evaluator and continuation input (#6556) ... * feat(goal): record the met goal and keep goal state on the history head - Add a goal_outcome LastValue channel (GoalOutcomeState). Only the guarded clear of a satisfied ordinary goal writes it, in the same checkpoint as the clear; the reply anchor is the latest visible AI message with text, the reply the visible signature keys on. A goal stored without created_at still clears and gets a record. - write_thread_goal removes the record on every other goal write and lists it in channel_versions, new_versions and metadata writes when it changes. Threads that never had a record keep their checkpoint shape. The sync-only SqliteSaver and CachedHistorySaver, which take the #6448 sync fallback, store and drop it the same way. - goal_outcome is server-owned: POST /state and non-internal run input that carry it get 400. A POST /state goal write, or a goal in external run input, clears it. - A branch head written onto its replay base resets the channels the head lacks, so a goal or record that write_thread_goal removed does not come back. Branching from the met turn keeps the record without the met goal. - The POST /history head now carries an active goal and an achieved goal_outcome, also before any message exists, so the post-run history refetch keeps them. Older entries stay title/thread_data. - contracts/thread_goal_contract.json pins the chat stand-down and check-failure codes, the record shape and status, the head keys and the host-written reasons. * feat(frontend): show why a goal stopped and when it was met - The goal bar derives its state from the active goal, the goal_outcome record and the messages: set, in progress, continuing, stopped (limit, auto-continue off, no progress, token budget, missing evidence, failed run, unknown code), waiting for you, waiting, couldn't check the goal, paused and goal met. An 8/8 stand-down now reads "Stopped" with the next step instead of "Continuing 8/8", and a count-0 stand-down no longer looks like a fresh goal. - "Goal met" shows while its anchor reply is the latest visible message (a visible human message, or a visible AI message with text, moves the chat on), so a reload agrees with the live view. An active goal wins over the record, and this tab's /goal set or clear hides it. - useActiveGoal drops the optimistic goal when the record of that same goal arrives, which fixes the bar that stayed after a goal met on the first run (the clear frame has no goal key), also for a goal stored without created_at. Server goal values pass through isGoalState; a /goal status read uses the backend's own active check, so the bar, the toast and the edit lock agree with the server. - Row 2 gives the reason and what to do next; Details holds the full goal, the checker's own note (never host-written text, a check failure or a paused goal's older check), the assumption note and an unknown code, and starts collapsed in each new state. The bar is a labelled section with a live region that announces state changes only (another goal's same state counts) and re-reads its text after a language switch. - The edit pencil on the latest turn is shown disabled with "Editing is off while a goal is set" instead of hidden; the message toolbar shows on focus-within, so keyboard users can reach it. - A /goal set or clear rejected with 409 keeps the draft and says a run is still going; other failures keep the server's message and the draft. A /goal request replaced by a newer one leaves the composer alone, so a double submit no longer empties it before the second one fails. - Copy lives in inputBox.goalBar (en-US, zh-CN); a contract test reads contracts/thread_goal_contract.json, and the raw-identifier guard now catches stand-down codes and goal field names. * test(frontend): cover the goal bar on both chat pages - tests/e2e/goal-status.spec.ts runs every case on the chat page and the agent chat page, since each wires the goal bar and the edit lock itself: a goal stopped at 8/8, one waiting for details and one waiting on an open question card show their reason and next step, also after a reload; the locked edit pencil gets keyboard focus, shows its toolbar and tooltip, does not open the editor, and hides while a file uploads; Goal met after one automatic follow-up (In progress, Continuing 1/8, then "Auto-continued once") survives a reload and hides after the next visible message; a goal met on the first run of a new chat replaces the set bar and frees the pencil, and a new /goal replaces Goal met while its own run goes on; a /goal set or clear refused with 409 keeps the draft for the retry and shows its own busy toast. - The mock POST /history head carries only the contract's history_head_keys, with goal only while active and goal_outcome only when achieved; thread state and run values omit an unset goal instead of sending goal: null. PUT and DELETE /goal drop the met record, setGoalWritesBusy returns the Gateway's 409, and a repeat create of a requested thread id returns the thread as is, like the Gateway. - The raw-identifier guard also catches checker blockers and the met record's field names. - frontend/src/AGENTS.md: the GoalStatus sentence now names goal, goal_outcome and useActiveGoal, reworded in place. * test(frontend): keep the draft through a failed upload and a busy /goal #6412 fires onSent only once a send is dispatched, so a failed upload keeps the text, files and stored draft. A /goal the Gateway refuses with 409 never reaches sendMessage, and the composer rejects it so PromptInput keeps the text. Drive both through the real sendMessage in one composer: a failed upload keeps "summarize it" stored, a busy /goal keeps its text and stored draft with no run, and the retry saves the goal and starts one run with the objective, not the "/goal" text. After that run the composer is empty and no stored draft comes back. * fix(frontend): drop the stop condition's closing period before the pause clause A stored stop condition often ends with a period, so the schedule card read "…remain)., pauses itself" (and "…。，满足后自动暂停" in Chinese). Trim the condition's closing sentence punctuation before the clause that follows it. The event line, where the condition ends the sentence, is unchanged. * fix(frontend): point "evidence missing" at the agent, not a user reply "Evidence missing" asked the user to reply with what's left, which is the push a goal is meant to save. It now asks the agent to show the result or explain what's missing, and offers /goal clear only for a goal that no longer applies: clearing drops the met record, so work that is right would never show "Goal met". zh-CN follows. Copy only: no key, state or mapping changes, and the scheduled page's reason labels are untouched. tests/unit/components/workspace/goal-status-next-steps.test.ts checks the row in en-US and zh-CN, and that no stop row offers /goal clear without that condition. goal-status.dom.test.tsx and goal-stream.dom.test.tsx now expect the new copy. * fix(frontend): say "Couldn't check the goal" once in the goal bar After a goal check that could not run, the bar's second line borrowed the scheduled page's whole reason, so it repeated the chip: "Couldn't check the goal · Couldn't check the goal; the run itself may be fine. It's checked again after your next message." Chinese had the same repeat. The line now gives only why the check failed ("The run itself may be fine", "No final reply was saved" or "The chat changed during the check"), then when it is checked again. The screen-reader announcement follows. The chip and the scheduled page's reason labels are unchanged. tests/unit/components/workspace/goal-status-unchecked.test.ts checks every check-failure code in en-US and zh-CN: the label appears once, and the line still says why the check failed. * feat(goal): redact the evaluator input when pii_redaction is enabled The goal evaluator calls its model directly, outside PiiRedactionMiddleware, so it sent raw user lines, tool arguments, tool results and Human Input Card answers even with pii_redaction enabled. With pii_redaction enabled: - the messages in the evidence window are redacted whole before the evidence caps can cut an identifier in two, as TitleMiddleware does. This reuses redact_queued_messages, which already covers content, call arguments and card answers. Earlier messages are left alone: the evaluator never sees them, and the pass is synchronous work on the event loop (0.84 s for an 800-message, 4 MB thread, 0.06 s for its window); - the assembled input, the goal objective included, is redacted again. A redaction error fails the check with evaluator_failed; raw text is never sent instead. When redaction is off, the input is byte-identical. Thread state keeps the raw text. README.md, config.example.yaml and the middleware docstring list the evaluator with the other redacted inputs. tests/test_goal_pii.py puts an address where the evidence caps cut a tool argument, a tool result and a card answer, and checks the objective, the unchanged input when redaction is off, that only the evidence window reaches the redactor and gives the same evidence as redacting the whole thread, that a redaction error stands down with evaluator_failed before the model is called, and the worker path. * fix(goal): redact the hidden continuation when pii_redaction is enabled The hidden /goal continuation repeats the goal objective and the evaluator's reason and evidence summary. PiiRedactionMiddleware skips it, since it is a framework message and not a user message, so with pii_redaction enabled each continuation turn sent them raw to the agent's model, and the message stayed in the thread for later model calls. The durable-context block and the evaluator input already redact the objective. With pii_redaction enabled, make_goal_continuation_message now redacts the objective, the reason and the evidence summary with redact_text before the message is built. The thread keeps the redacted message, which the UI hides; the goal state keeps the raw objective. The worker builds the message before it counts the continuation. A redaction error fails the check the way an evaluator redaction error does: run_failed with stand_down_reason evaluator_failed, the goal stays active, nothing is sent and the continuation budget is not spent. Only the exception type is stored. With redaction off, the message is byte-identical. README.md, config.example.yaml and the middleware docstring list the continuation with the other redacted inputs. tests/test_goal_continuation_pii.py checks the redacted objective, reason and evidence summary against the tokens redact_text gives, the unchanged message with redaction off or no config, the worker path under the run config, and a redaction error. * docs(changelog): link the goal outcome entries to #6556 Fill the four ([#PR]) placeholders in CHANGELOG.md and CHANGELOG_zh.md with this PR's number and add the matching link references. * fix(frontend): keep an active goal stored without timestamps visible POST /threads/{id}/state and run input can store an active goal without created_at or updated_at. The backend still evaluates it and rejects an edit with 409 (is_active_goal checks only status "active"), but isGoalState required both timestamps, so history and live values dropped it: both chat pages hid the goal bar and unlocked the last-turn pencil, and only a /goal status read, which used a looser predicate, brought them back. isGoalState now accepts any record with a string objective and status "active", and normalizeGoalStatusRead uses it, so thread values, live updates and status reads share one rule. Malformed or inactive values are still dropped. Tests cover a sparse active goal from the history head and from a live update before the post-run refetch (bar shown, hasGoal true), and a malformed goal that stays hidden. * test(goal): check the outcome write metadata the same way on every saver PostgresSaver stores checkpoint metadata through get_serializable_checkpoint_metadata, which drops "writes", so the [postgres] case of test_goal_outcome_round_trips_through_the_sync_fallback failed with KeyError: 'writes' when CI ran it against a live database. The test now records the metadata write_thread_goal passes to put and asserts the clear's and the next goal's "writes" there, for every saver. The stored channel values are checked as before, and on sqlite and cached-sqlite the stored "writes" must still equal what was passed. * docs(agents): keep goal_outcome out of the agents guidance chain The middlewares AGENTS.md chain is already over the 98,304-byte AG002 hard limit on main, and the PR-mode check fails any chain a PR touches, so adding goal_outcome to the ThreadState field list in deerflow/agents/AGENTS.md failed the agent-guidance job. goal_outcome stays documented in runtime/AGENTS.md and backend/app/gateway/AGENTS.md, which are outside that chain. * refactor(goal): read the evaluator's evidence and redaction from one window format_visible_conversation recomputed the window start that the redaction pass takes from _evidence_window. Both now use _evidence_window, so a later change to the cap or to what counts as visible moves both. The window test now fills the window with tool-only replies and tool results. Before, it caught a cap change in one copy but not a change to what counts as visible. --------- Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-10 00:20:45 +08:00
LingYi	1c3b20b1bf	fix(channels): preserve inbound files on concurrent uploads (#6476) ... * fix(channels): preserve inbound files on concurrent uploads Claim IM attachment destinations exclusively and retry filename collisions. Preserve default replacement behavior and Gateway conversion-link compatibility. * fix(channels): claim embedded upload destinations exclusively Retry competing publications in Feishu and DingTalk without replacing their bytes. Cover mounted and remote sandbox paths, and keep returned filenames consistent. --------- Signed-off-by: LingYi <lingyi01525@gmail.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-09 20:56:26 +08:00
zeng-bohan	c6ad5ed93c	fix(gateway): classify duration-only checkpoints without the Postgres-dropped marker (#5988) ... * fix(gateway): classify duration-only checkpoints without the Postgres-dropped marker On Postgres the savers funnel metadata through langgraph's get_serializable_checkpoint_metadata, which pops writes before the row lands, so persist_run_history_metadata's runtime_run_duration marker never comes back and every replay/history read path treats metadata-only duration leaves as addressable conversation state. is_duration_only_checkpoint now classifies in two tiers: - writes present (memory/SQLite) is authoritative — the per-writer key is exact, so a title leaf carrying runtime_interrupt_title with inherited run_durations is not a duration checkpoint; - writes absent (Postgres) falls back to the surviving stamps (source == run_durations / run_message_ids keys). Stamps alone are not exact: _ensure_interrupted_title and _rollback_to_pre_run_checkpoint copy the head's metadata and inherit them. Read paths tolerate that because every stamp-bearing leaf either copies its parent's messages verbatim or restores an ancestor's exact message state, so a skipped leaf only advances a message-presence scan onto a state-equivalent checkpoint. Destructive callers opt out via stamp_fallback=False: enforce_thread_retention keeps widening the class only through the parent-shape check in _mark_duration_leaves_without_the_marker. * fix(gateway): confirm the duration stamp fallback by parent shape Review on #5988 surfaced a real false positive: write_thread_goal copies the head's metadata and thereby inherits the run_durations/run_message_ids stamps while changing the goal channel, and on Postgres its own writes.goal marker is popped too — so the stamp fallback classified the goal leaf as duration-only and the branch scan walked past it, copying channel values from before the goal write. The stamp fallback now also requires the duration writer's shape: it clones the parent's channel_versions verbatim, while every state-changing leaf (title, goal) bumps at least one version. Callers resolve the parent from their own context — the lineage walk fetches the grandparent only for stamp candidates, the history-window scans (branch, latest-turn, regenerate filter, chronological fallback) index the window they already hold — and stamps without a resolvable parent are refused: scanning one state-equivalent copy is free, skipping a goal leaf is not. Also corrects the mechanism claims from the first pass: langgraph's update_state paths (rollback, compaction, manual updates) persist metadata built from scratch and cannot inherit the stamps at all; the inheriting writers are title and goal. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(gateway): share the stamp gate and reuse the walked grandparent Review round 2 on #5988 — all three items, no functional changes: - extract _has_postgres_stamps as the single gate shared by the classifier fallback tier and the walk probe, so widening one widens the other; - carry the grandparent fetched for a stamp candidate into the next iteration (it is exactly the next parent), turning a chain of N Postgres duration leaves from ~2N+1 ancestor reads into N+1; - pin the unresolvable-grandparent promise at walk level: a stamp candidate whose own parent link was pruned stays addressable and remains the replay base. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(gateway): resolve persisted channel versions for the duration stamp fallback Materialized accessor snapshots expose no checkpoint payload, so the verbatim-copy shape check always failed open and Postgres duration leaves stayed addressable. Carry the version maps alongside the snapshots (raw snapshots expose them directly, graph-backed ones re-read the raw tuple through the accessor) and use them at every replay-base scan site. * perf(gateway): resolve stamp-fallback versions lazily and once per tuple The Postgres stamp fallback needs the raw channel versions for its shape check, and both window scans resolved them eagerly for every entry: a branch request paid up to 2N serial roundtrips for a window of N, and the regenerate scan resolved the same tuples a third time through resolve_history_versions. Resolve them only for stamp candidates - the marker tier and the stamp gate decide without versions - and memoize by config identity, so a marker-decided window pays nothing and each distinct tuple pays at most one raw read. The lineage walk had the same shape: a stamp candidate the shape check refuses re-read its grandparent as the next iteration's parent, because the prefetched slot was only filled when the candidate was skipped. Ancestor reads are now memoized by config identity, so no ancestor is fetched twice. Dropped the dead checkpointer parameter of find_checkpoint_before_message_chronologically: no caller passed it, and wiring one in from an async handler would put a blocking get_tuple on the event loop. --------- Co-authored-by: zeng-bohan <310902929+zeng-bohan@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-09 20:30:19 +08:00
Hyeonsang Cho	b842e06be1	fix(channels): send the CSRF pair on IM /goal writes (#6537) ... * fix(channels): send the CSRF pair on IM /goal writes `/goal <objective>` and `/goal clear` from an IM channel sent their PUT/DELETE to the Gateway with only the internal auth headers. The Gateway's CSRF middleware does not exempt internal auth, so with auth enabled (the default) both writes were rejected with 403 and the channel replied "Failed to set goal." / "Failed to clear goal.". `_goal_request` now sends the same double-submit cookie/header pair as the channel's LangGraph SDK client; both build it from one helper, `ChannelManager._csrf_headers()`. * docs(changelog): reference #6537 --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-09 17:58:09 +08:00
yu1128-L	927ecb756f	docs(api): document MCP task router endpoints (#6559) ... Co-authored-by: yu1128-L <296164533+yu1128-L@users.noreply.github.com>	2026-10-09 17:23:54 +08:00
Hyeonsang Cho	9c159ef880	fix(auth): key the compose login lockout by client, not by nginx (#6519) ... * fix(auth): key the compose login lockout by client, not by nginx Failed logins are counted per client IP, and the Gateway honors X-Real-IP only from a peer listed in AUTH_TRUSTED_PROXIES. The compose files never set it, and every browser request reaches the Gateway from the nginx container, so all logins shared nginx's address: five wrong passwords from anyone locked every user out for five minutes. AUTH_TRUSTED_PROXIES now also accepts hostnames, resolved off the event loop and cached for 10 seconds (failed lookups included, and only when X-Real-IP is present), and both compose files default it to the bundled nginx service, whose address Docker assigns. nginx overwrites X-Real-IP with $remote_addr on every Gateway route; a test pins that for the three maintained configs. * docs(changelog): reference #6519 * fix(auth): share one trusted-proxy lookup across concurrent cache misses A burst of setup-status / login requests on an expired hostname entry started one getaddrinfo per request while DNS was slow, occupying the default executor that password verification also uses. The cache check and an in-flight task registration now happen without a yield between them; later callers join that task through asyncio.shield, so a cancelled request cannot cancel the lookup the others joined, and the task caches its own result. The compose default keeps `:-` on purpose: every browser request arrives through nginx, so an empty AUTH_TRUSTED_PROXIES would only bring back the shared lockout. The compose comment and .env.example say so, and the rendered-compose test now covers the explicitly empty value. * fix(docker): keep a .env AUTH_TRUSTED_PROXIES under make docker-start docker.sh start runs Compose from docker/ without --env-file, so the dev compose file's ${AUTH_TRUSTED_PROXIES:-nginx} interpolated from the shell only, and the resolved environment entry outranked the operator's value loaded through env_file. Export it from .env alongside the proxy variables (a shell export still wins), and strip a CRLF before the quotes. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-09 17:22:45 +08:00
RongJie G	8b8fdf4387	fix(gateway): make resume retries idempotent (#6499) ... * fix(gateway): make resume idempotency command-aware Signed-off-by: CorgiBoyG <111257566+CorgiBoyG@users.noreply.github.com> * docs(gateway): document keyed resume rollout restrictions --------- Signed-off-by: CorgiBoyG <111257566+CorgiBoyG@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-09 17:11:00 +08:00
Hyeonsang Cho	c58d04b6b6	fix(scheduler): keep a one-time task's scheduled run after an early trial (#6512) ... * fix(scheduler): keep a one-time task's scheduled run after an early trial "Run once now" on a once task before its run time launched the trial as the task's own run: the launch marked the task running and finalize_occurrence then mapped the trial's outcome to completed, failed or cancelled. claim_due_tasks only claims enabled tasks, so the run never fired at run_at although next_run_at still showed it. A manual trial launched while next_run_at is still ahead now leaves the parent status and next_run_at unchanged, like a trial on a recurring task, at launch, in finalize_occurrence and in the launch repair (_associate_task_with_run). A trial after the run time has passed is still the task's run. * docs(changelog): reference #6512 * refactor(scheduler): scope the once-trial rule to once tasks and link its launch twin * fix(scheduler): keep a newer due-task claim through late launch bookkeeping With early trials leaving a once task enabled, the poller can claim the now-due task after the trial finished but before the trial's launch bookkeeping commits. That late update_after_launch passed can_project (the claim had not allocated an occurrence yet), kept the claim's "running" status under protect_terminal, and cleared the claim's lease, so the poller's admission was rejected as stale and the task was left running with no lease and no occurrence: unclaimable, and finalized from the trial by stuck-once recovery. A launch write identified by its occurrence never owns the parent lease (scheduled admission releases the claim with the queue insert, and a manual trial takes none), so update_after_launch now clears the lease only for a write with no occurrence row, which is the claimer's own pre-admission failure. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-08 23:34:32 +08:00
Nan Gao	b99ac916b6	fix(auth): count login lockouts in the database across Gateway replicas (#6501) ... * fix(auth): count login lockouts in the database across Gateway replicas POST /api/v1/auth/login/local throttled failed logins per client IP in a module-level dict, so with N Gateway replicas behind one load balancer an attacker got N x auth.local.max_login_attempts guesses and a lockout on one replica was invisible to the others. Move the counter behind a LoginThrottleStore (deerflow.persistence. login_throttle): MemoryLoginThrottleStore keeps the historical per-process semantics and 10k tracked-IP bound; SqlLoginThrottleStore shares one login_throttle row per IP through the application database, incrementing and starting the lock in a single dialect-native upsert, applying check decisions with compare-and-set predicates in a separate write transaction, and sweeping served locks plus 24h-idle counters in bounded batches. Both stores pin the existing contract: the lock starts when the count reaches max_login_attempts, the committed duration is honored when the policy shrinks mid-lock, a served sentence is never resurrected, tightening keeps the count, success resets the IP, and the 429 status and message are unchanged. New startup-only selector auth.local.throttle_storage (auto | memory | db, default auto = the database whenever database.backend is sqlite or postgres). The Gateway installs the store once at startup after the persistence engine; deps._validate_login_throttle_storage warns when a multi-process deployment keeps memory. Migration 0034_login_throttle creates the table; config_version 55 -> 56 in config.example.yaml and the Helm chart. Docs: README, CONFIGURATION.md, AUTH_DESIGN.md, config and migrations AGENTS.md, CHANGELOG. * docs(changelog): link the login throttle entry to #6501 * fix(auth): re-check expiry on the row the login-throttle sweep deletes The bounded cleanup in SqlLoginThrottleStore.record_failure deleted `WHERE ip IN (SELECT ip ... WHERE <served or stale> LIMIT 200)`. On PostgreSQL READ COMMITTED the expiry predicate applied only inside the snapshot-bound subquery: when the DELETE had to wait on a row lock held by a concurrent check() that was extending the same lock under a raised lockout_seconds, PostgreSQL re-evaluated only the outer WHERE on the updated tuple, IP membership still held for the old candidate, and the now-active lock was deleted; the next attempt from that IP got a clean record and reached password verification (review of #6501, P2). Repeat the served/stale predicate on the DELETE target as well (SqlLoginThrottleStore.sweep_statement), keeping the bounded candidate subquery, so the re-evaluation sees the updated row's expiry. The other writes already carry their full compare-and-set predicate on the target row: _discard and the check() UPDATE both use _matches (ip, fail_count, locked_at, lock_duration_seconds), so a tuple changed while they waited no longer matches and the stale decision is skipped. _discard keeps the equality compare-and-set rather than adding an expiry condition: its early-release branch deletes a lock whose committed sentence has not elapsed under the lowered live policy, which an expiry predicate would wrongly block, and the equality predicate already pins every input of the decision. reset stays unconditional by design. Tests: a dialect-compile test asserts the DELETE's own WHERE carries the expiry predicate for postgresql and sqlite (red on the previous HEAD), and a PostgreSQL-only test (skipped without TEST_POSTGRES_URI) reproduces the update-versus-sweep interleaving with two engines, waiting on pg_stat_activity for the sweep to block before the extender commits. Docs: sql.py concurrency contract and the migrations guide's 0034 bullet. * fix(auth): keep an active login lock's clock and fail closed on explicit db Address the "changes requested" review on #6501. Lock clock (confirmed defect): record_failure re-stamped locked_at = now for every failure on an already-locked row, so a sustained attacker's sentence slid forward with each attempt. Both stores now apply one rule in one atomic decision: new_count = fail_count + 1; below max_attempts the IP counts with no lock (a failure after the operator raised the threshold clears an existing lock); at or over it, a failure during an *active* lock keeps locked_at and the committed lock_duration unchanged, while a never-locked or served row starts anew with now / lockout_seconds (so the failure that reaches a raised threshold starts a fresh lock rather than keeping a stale locked_at). The SQL upsert expresses it as nested case() on the row's own values; the memory store mirrors it. The sweeps in both stores now leave the row being recorded to that decision instead of deleting a served lock or stale counter first, which split the contract (SQL would have produced a fresh (1, NULL, NULL) row). base.py states the rule. Explicit db downgrade: resolve_login_throttle_store raises SystemExit — the failure type of the other startup validations in app.gateway.deps — when throttle_storage='db' resolves to the shared table but no engine is initialised, so langgraph_runtime refuses to start instead of silently running every replica on per-process counters; the lazy bare-app path applies the same rule and installs nothing. 'auto' keeps warning and falling back. 'db' on a memory database still degrades with a warning (there is no shared table to insist on). Non-blocking items: _key() logs a warning when a client key is truncated to 255 characters (never the key itself); the sql.py docstring covers wall-clock locked_at across replicas (run NTP; skew shifts evaluation by that much) and why STALE_COUNTER_SECONDS=24h / SWEEP_BATCH_SIZE=200 were chosen; a store-level blocking-I/O anchor covers the SQL reset path; the _validate_login_throttle_storage warning was verified to render 'throttle_storage=memory' for the StrEnum (the gate test now passes the enum member and asserts that text). reset stays unconditional: a peer failure that commits after a reset leaves fail_count=1, one genuine failure after the cleared history, which a new test documents. Docs: CHANGELOG entry, config.example.yaml, CONFIGURATION.md, AUTH_DESIGN.md and the throttle_storage field description. * fix(auth): re-evaluate a login-throttle check whose compare-and-set missed SqlLoginThrottleStore.check applied its decision (commit the live duration, or clear a served / released lock) with a compare-and-set predicate on the snapshot it had read, but ignored the affected-row count. When a peer changed the row between the read and the write — an admitted wrong password incrementing fail_count on another replica, or a successful login clearing the row — the UPDATE or DELETE matched zero rows, yet check reported the decision as applied: it could return an extended 60s sentence while the row kept its 1s duration, so the next check cleared the lock and let password verification through; a live duration decrease could be dropped the same way; and a row a peer had just cleared was still reported as locked (#6501 review, P2). Every compare-and-set write in check now checks result.rowcount. On a miss the row is re-read and re-evaluated from the top, up to CHECK_CAS_ATTEMPTS (3) times, applying a fresh compare-and-set decision on the new snapshot and never clobbering a reset or replacement: a row that is gone is reported as allowed, a fresh peer lock is reported as locked, and an incremented count gets the extension or decrease committed on it. Exhausting the bound fails closed: nothing is written and the answer is the last snapshot's lock under the live policy, logged at debug. The read stays in its own short transaction and each write in a separate one. The evaluation is now one shared pure function, evaluate_check in base.py (CheckDecision), used by both stores so the contract cannot diverge. The memory store keeps a single pass: its compare-and-set cannot miss because there is no await between the read and the write on the loop thread, which its docstring now states. Tests (red first on df26c2acf) use a session proxy that runs the peer mutation on a second engine right after the snapshot read ends its transaction: the reviewer's raised-duration interleaving (59.5s reported and committed, the increment survives, a later check still locked), the mirrored decrease, early release on the fresh row, a reset landing between read and write (0.0, no row recreated), and the bound-exhausted fail-closed case. * docs(changelog): resolve merge markers left in the Unreleased section * test(migrations): pin 0035_login_throttle as the head in the 0034 watermark test Upstream #6477 added test_migration_0034_run_event_seq_watermark.py asserting 0034 is the single head; this branch chains 0035_login_throttle after it, so the test now pins the current head and walks the chain like its siblings. * perf(auth): one session per login-throttle check, one transaction per failure Two non-blocking performance suggestions from the #6501 review. Single session per check. The router probed the row with store.get() and then called store.check(), which re-read it: a recorded IP cost two connection-pool checkouts and two SELECTs per request on the unauthenticated login path, letting a lockout flood compete with legitimate traffic for Postgres connections. LoginThrottleStore.check now takes the policy as an async callable (LoginThrottlePolicy) and resolves it lazily inside the store: the probe, the policy resolution and the compare-and-set loop share one session, a clean IP returns 0.0 without ever calling the policy (the config.yaml read is still skipped for the common case), and a recorded IP resolves it exactly once, also across compare-and-set retries. The decision is made on a snapshot read after the resolution: the policy read is a yield point, and a decision that needs no write has no compare-and-set to catch a row a peer changed meanwhile — so one session, but still a read after the yield. The memory store takes the same signature and re-reads its record after the await for the same reason. The router passes its asyncio.to_thread policy read as the callable and drops the separate probe; get stays on the protocol for tests and anchors. No short-TTL verdict cache: it would mask a successful login's reset for the TTL window, and the single session already halves the hot path. Sweep in the upsert's transaction, plus an index. record_failure ran the housekeeping DELETE in its own transaction and the upsert in a second one, two commits (two WAL flushes on PostgreSQL) per failed login; the sweep now rides in the upsert's transaction with one commit, the keep exclusion already protecting the row being recorded. The new ix_login_throttle_updated_at (ORM __table_args__ and the unreleased 0035 migration, created after the table and dropped before it, each guarded separately so a table left by an interrupted attempt still gets its index) serves the sweep's stale-counter predicate; the served-lock predicate scans a table the sweep itself keeps small. Tests (red first on a137fbc47): a clean IP never resolves the policy and a recorded IP resolves it exactly once (both stores), the SQL store opens exactly one session per check and commits once per record_failure (counting wrappers), the migration test asserts the index after upgrade, after completing a partial upgrade that lacked it, and gone after downgrade while compare_metadata stays empty; the router-level "mutated during policy resolution" tests now inject their mutation through the policy callable. * docs(changelog): note config_version 57 in the login throttle entry	2026-10-08 22:35:19 +08:00
NanPan	62c54238d2	fix(channels): fence restart during service shutdown (#6503) ... * fix(channels): fence restart during service shutdown * test(channels): fence restart during service stop * test(channels): exercise restart after shutdown channel snapshot * docs(channels): document service shutdown publication fence * fix(channels): keep agent guidance within CI hard budget * fix(channels): fence publication after shutdown completes * test(channels): cover resume after completed service shutdown * test(channels): mark direct-start fixtures as active services * test(channels): mark direct-start fixtures as active services * style(channels): format shutdown regression test * fix(channels): drain channel startup completing after service stop * test(channels): ensure late channel startup is drained after stop * style(tests): format channel shutdown regression --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-08 22:29:49 +08:00
Nan Gao	5ae953fc2f	fix(memory): keep the retrieval index Pod-local and refresh scopes written by peers (#6494) ... * fix(memory): keep the retrieval index Pod-local and refresh scopes written by peers DeerMem's derived SQLite FTS5 index for every user was one WAL database pinned to {storage_path}/.retrieval. With several Gateway Pods sharing one home volume each Pod opened that file over a network filesystem (unsupported by SQLite), every Pod start emptied and refilled it under its peers, one Pod's corruption recovery deleted files the others held open, and a Pod never learned that a peer had written a user's facts, so memory_search served stale results. - New backend-private key memory.backend_config.retrieval_index_path: empty keeps {storage_path}/.retrieval, a relative path resolves against storage_path, an absolute path is used as-is. The full rebuild and the corruption recovery act only on that configured index. - rebuild_index records each agent scope's manifest signature (mtime_ns, size, revision) before reading its facts; search_facts rebuilds a scope whose live signature differs because another process wrote the user's memory. An own commit advances the recorded signatures of that user's scopes only when they were in sync at the previous revision, so own writes never rebuild while an interleaved peer write still does. - Gateway startup warns, in the style of _validate_agent_storage, when a declared multi-instance deployment keeps the DeerMem index inside storage_path. - config.example.yaml documents the key; config_version 55 -> 56, mirrored in the Helm chart and its README. - Helm mounts an emptyDir at /var/lib/deerflow/memory-index, points the key at it, drops the legacy memory.storage_path: memory.json line, and documents the memory layout next to the other multi-replica prerequisites. * docs(changelog): link the memory retrieval index entry to #6494 * fix(memory): never advance the index signature on a no-op commit and resync whole scopes Two review findings on the cross-replica retrieval re-sync: - save() and apply_changes() inferred the replaced manifest revision as "returned revision - 1". The commit helper returns the existing manifest unchanged for a no-op (unchanged-value or empty change set), so after a peer bumped the manifest an own no-op write advanced this process's stale index signature to the peer's revision without carrying the peer's delta: a fact the peer deleted stayed searchable until the manifest changed again. Both paths now read the real pre-commit revision under the user lock and pass committed=(pre_revision, signature) only when the commit produced a new revision; a no-op passes None so the next search still rebuilds the scope. - The scoped rebuild (signature mismatch and the pre-existing dirty-scope path) listed facts through list_facts() with its default limit of 100 and then replaced every row of the scope, so a scope with more than 100 facts lost its tail on the first re-sync. It now reads the scope's complete fact list. * fix(memory): fence index signature promotion against a concurrent scope rebuild Review finding on the cross-replica re-sync: a successful adapter notification does not prove its delta is still in the index when the signature is promoted. The SQLite lock covers single adapter calls only, and neither the scope lock nor DeerMem's warm-up lock spans "notify, then promote", so rebuild_index can replace a scope's rows in between. After a peer summary-only commit (r+1), A's search starts a scoped refresh that captures the r+1 signature and reads f1/f2; A's own deletion of f2 commits r+2 and removes the row; the refresh then installs its stale f1/f2 and marks the scope synced at r+1; the deletion resumes and promoted that signature to r+2, so later searches saw the live signature as equal and kept returning the resurrected f2 until another manifest change. Mechanism: a generation fence rather than a lock. rebuild_index bumps a per-scope generation (scoped rebuild) or a storage-wide generation (full rebuild) under _cache_lock whenever it publishes or forgets a scope's rows, in both mark_synced and forget_synced. _dispatch_retrieval_notifications snapshots the generations under _cache_lock before its first adapter call and, at promotion time, skips every scope whose generation moved (and everything when the storage-wide generation moved), leaving the rebuild's own captured signature in place; that signature predates the commit, so the next search's comparison rebuilds the scope. A lock would have had to serialize notification plus promotion with bulk install plus publication while search_facts -> rebuild_index -> load() already takes the scope, file and cache locks; the fence adds no lock-order obligations and only costs a redundant rebuild in the rare race. Every interleaving is covered: a rebuild that completes before the snapshot is reflected in the captured generation and promotion proceeds on an index that carries both the rebuild's rows and this write's delta; one that publishes between snapshot and promotion is skipped; one that publishes after the promotion records its stale captured signature, which the next search catches. Tests reproduce both orders deterministically with threading.Event ordering (adapter wrapper that holds the bulk install and the remove notification): test_promotion_is_fenced_against_a_refresh_that_installs_in_between (red before the fix) and test_stale_refresh_installing_after_a_promotion_is_caught_by_the_next_search (regression guard for the mirrored order). * fix(memory): publish a rebuild's signature under the lock that replaced its rows Review finding on the cross-replica re-sync: two peer-triggered refreshes of one scope could replace rows in one order and publish their captured signatures in the other. On a warmed Pod A, refresh R1 captures r+1 with f1/f2 and waits before installing; a peer deletes f2 at r+2; refresh R2 captures r+2, installs f1 only and pauses after bulk_rebuild returns, before mark_synced; R1 installs its stale f1/f2 and publishes r+1; R2 then publishes r+2 over R1's rows. Later searches saw the live signature as equal and kept returning the deleted fact. The generation fence only guards own-write promotion, and the adapter's SQLite lock ends when the install returns. Mechanism: a per-storage _retrieval_publish_lock held across the row replacement and the signature publication, for the bulk path (bulk_rebuild + mark_synced / forget_synced) and the clear+upsert fallback, scoped and full alike. Overlapping refreshes of a scope therefore serialize their install+publish pairs: whichever installs last also publishes last, and a stale captured signature published last differs from the live manifest, so the next search's compare rebuilds the scope. Fact reading (load() / the glob) stays outside the lock so a slow read never blocks refreshes of other scopes. The startup full rebuild holds the lock for its single bulk install; scoped refreshes wait for it, which is acceptable because before warm-up completes a search would be rebuilding its scope anyway (DeerMem.warm_retrieval takes its own _retrieval_lock only after rebuild() returns, so the two never nest). Lock order: the publish lock is acquired with no storage lock held -- search_facts releases _cache_lock before calling rebuild_index, reload() leaves its scope/file-lock block before rebuilding, and DeerMem._ensure_retrieval_scopes holds only its outer RLock, which nothing inside rebuild_index acquires. Inside the lock only the adapter's own lock and _cache_lock are taken, and both are leaf locks that never call back into storage, so no cycle is possible. Test: test_rebuild_publication_stays_ordered_with_row_replacement drives the reviewer's interleaving with threading.Event ordering (red before the fix). The pause harness now holds a refresh after its fact read, outside the publish lock, instead of inside the adapter's rebuild, so the earlier fence tests keep their semantics without holding the new lock while paused. * fix(memory): read each manifest once per full rebuild and serve the local index on a compare read error Two suggestion-level review items on the cross-replica retrieval re-sync. - The full rebuild cached manifest signatures keyed by (manifest path, agent name), but _scope_signature reads only the manifest file -- every agent bucket of a user shares one memory.json -- so the startup scan stat+read+ parsed the same file once per bucket that has facts. The cache is now keyed by the manifest path alone while synced signatures are still recorded per (user, agent) scope: users manifest reads instead of users x agents. - The per-search freshness compare put a shared-volume manifest read on every search_facts call, and _load_memory_file raises MemoryStorageCorruption on OSError and malformed JSON, so a transient network-filesystem read error or a corrupt memory.json failed a search the Pod-local index could still answer. The compare now catches OSError, ValueError and MemoryStorageCorruption: it logs a warning naming the scope (traceback at debug), serves the current local index for that scope and leaves the recorded synced signature untouched so the next search compares again. It deliberately does not mark the scope dirty: a scoped rebuild would hit the same failing read, forget the scope's signature and fail the search path too. * docs(changelog): resolve merge markers left in the Unreleased section * fix(memory): forget a scope's index signature when an own delta cannot be proved compatible Review finding on the cross-replica re-sync: skipping promotion left a newer rebuild's signature trusted even after this dispatcher had overwritten its rows with an older notification. On a warmed Pod A, an own PATCH of f2 commits r+1 and pauses after releasing the user lock, before its adapter upsert; Pod B deletes f2 at r+2; a concurrent search on A detects the peer change, rebuilds the scope without f2 and publishes r+2; the pending r+1 upsert then reinserts the deleted fact, and the revision check merely skipped because the synced revision was r+2 rather than the PATCH's previous r. The signature stayed equal to the live manifest, so searches returned the deleted fact indefinitely. The generation fence could not help: it only suppresses promotion, the stale adapter mutation still happens. Rule: after an own commit's notifications are applied, the mutated scope's recorded signature may stay only when the delta is provably compatible with the published snapshot -- the scope is synced at exactly previous_revision and no rebuild published rows for it (or storage-wide) since the fence snapshot -- in which case it is promoted as before. In every other case where this dispatcher mutated the adapter for the scope (synced at another revision, newer or older; generation moved; not synced at all; or notifications without a committed revision, i.e. migration and clear paths) the scope's signature is forgotten so the next search's compare rebuilds it. The user's other scopes were not mutated by this delta: they are promoted when provable and otherwise left untouched. The decision runs under _cache_lock together with the generation reads, so a rebuild publishing concurrently is either observed or observes the forget; the failure path (dirty + forget) is unchanged. Orders covered: the reviewer's (publish r+2, then the stale upsert) forgets and the next search rebuilds without f2; the earlier fence order (publish between adapter op and promotion) now forgets too, one redundant rebuild; no concurrent rebuild promotes exactly as before. Test: test_stale_own_delta_replayed_over_a_newer_snapshot_forgets_the_scope holds the PATCH's adapter upsert after the user lock is released (new pause_next_upsert hook on the test adapter), Event-ordered, red before the fix. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-08 21:20:45 +08:00
NanPan	1a88f29bf7	fix(channels): snapshot outbound listeners per message (#6502) ... * fix(channels): snapshot outbound listeners per message * test(channels): cover listener registration during dispatch * docs(channels): document outbound listener admission snapshot * docs(channels): keep guidance under size limit * docs(channels): clarify outbound snapshot unsubscribe semantics * test(channels): pin outbound unsubscribe snapshot semantics * docs(channels): keep outbound snapshot guidance within size limit --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-08 20:22:28 +08:00
Nan Gao	4bab280250	fix(skills): share skill cache invalidation across Gateway replicas (#6495) ... * fix(skills): share skill cache invalidation across Gateway replicas SkillStorage.load_skills() rescans disk and re-reads extensions_config.json on every call, but the prompt layer in deerflow/agents/lead_agent/prompt.py caches the enabled-skills list, the per-(app_config, user_id) entries and the rendered <skill_system> section per process, and every skill mutation in routers/skills.py only refreshed the process that handled it. With several uvicorn workers or several Pods sharing one home volume, a skill installed, edited, deleted, rolled back or toggled through replica A kept being offered as the old skill set by replica B until B restarted, and POST /api/skills/reload had to be sent to every Pod separately. Reuse the MCP cache-reset mechanism. A new generic helper, deerflow.config.shared_reset_marker, owns a hidden JSON marker beside the resolved extensions config (.<config name>.<suffix>.json): publish() replaces it atomically with a random generation under extensions_config_write_lock + extensions_config_file_lock, chaining previous_generation and an optional user_id; SharedResetMarkerTracker polls it at most once per second (monotonic clock, never blocking behind a concurrent poller), adopts the current state silently on its first poll, and classifies a change as user-scoped only when exactly one publication carrying that user happened since the last poll. deerflow/mcp/cache.py now builds its .<config>.mcp-cache-reset.json marker through the same helper with no behavior change. prompt.py publishes .<config>.skills-cache-reset.json via publish_skills_cache_reset(user_id=...) and checks the marker on every cache lookup (global cache, per-config cache, prompt-section LRU, user scoped entries), calling _invalidate_enabled_skills_cache() or invalidate_user_skill_cache(). The publishing process remembers its own generation so it does not retire the caches it just rebuilt. Every mutation tail in routers/skills.py (install/upload, edit, delete, rollback, enable/disable, reload) refreshes locally and then publishes the marker off the event loop; /skills/reload answers scope=shared_config, or scope=process when no extensions config path resolves, and a marker publication failure is a 500 so a 200 never means only one process was refreshed. Docs: README, backend/docs/API.md, skills/config/mcp/gateway AGENTS.md, and frontend skills.mdx (en/zh; also fixes the reference to a non-existent skills/loader.py) describe the shared invalidation and drop the per-Pod guidance. CHANGELOG entry under Unreleased / Fixed. * docs(changelog): link the skills cache reset entry to #6495 * fix(skills): drain the reload tail and keep marker failures out of 404 Two review follow-ups on the shared skills cache reset (#6495). POST /skills/reload awaited the local refresh and the marker publication unshielded. CancelledError is a BaseException, so a caller that disconnected between the two slipped past the `except Exception -> 500` mapping, surfaced no error, and left every peer replica serving the old skill set -- the one outcome the operator hook for external mount writes exists to prevent. The refresh and the publication now run as one `await_drained(_drain_skill_mutation("reload", ...))` tail, the same discipline the install/edit/delete/rollback/toggle tails already use; the exception -> 500 mapping and the scope response are unchanged. Publication errors could surface as 404. resolve_shared_config_path() only swallows the resolution-time FileNotFoundError; a config directory that vanishes between resolution and the lock file / atomic replace still raised FileNotFoundError from the marker write, and the install, edit, delete and rollback handlers mapped that to HTTP 404 with the raw OS error text for a skill that had in fact been applied. publish_skills_cache_reset() now re-raises OSError (and a misconfigured project root's ValueError) as SkillCacheResetPublishError, a RuntimeError that no handler maps to 404/400, so every handler reports it through its generic 500 branch; the message names only the exception type, never a server path. The install handler gains an explicit clause that pins that contract beside its 404 mapping. Tests: cancelling reload after the refresh still publishes the marker; a FileNotFoundError from the marker write yields 500 (not 404) for install, edit, delete and rollback, 500 for the public toggle and the generic reload error; the wrapper type is not an OSError.	2026-10-08 19:43:04 +08:00
NanPan	fa3bb438c9	fix(gateway): bound subagent batch shutdown (#6434) ... * fix(gateway): bound subagent batch shutdown * test(gateway): cover bounded subagent batch shutdown * fix(subagents): cancel batch work before stop drain * test(subagents): pin cancellation before stop drain * test(gateway): account for subagent shutdown budget * docs(helm): refresh gateway shutdown budget * docs(compose): refresh gateway shutdown budget * docs(compose): correct gateway shutdown total --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-08 09:55:54 +08:00
NanPan	7dedb10dca	fix(scheduler): serialize notification worker lifecycle (#6433) ... * fix(scheduler): serialize notification worker lifecycle * test(scheduler): bound lifecycle wait	2026-10-08 09:26:31 +08:00
Nan Gao	5e3c24fe94	fix(gateway): probe the Redis stream bridge and provisioner in /health/ready (#6447) ... * fix(gateway): probe the Redis stream bridge and provisioner in /health/ready GET /health/ready only probed the ORM engine and the LangGraph checkpointer. The Redis stream bridge client connects lazily and nothing ever pinged it, so a Gateway whose Redis was down started, answered 200 ready to the Kubernetes readinessProbe and Compose healthcheck, and kept receiving traffic while every run's first publish failed. Since #6328 the Redis bridge is mandatory for multi-instance deployments, so such a replica is not serviceable at all. - StreamBridge gains `async ping() -> bool`; the base returns True (no external backend), RedisStreamBridge round-trips PING and answers False on RedisError. - /health/ready adds a `stream_bridge` probe (not_configured for the memory bridge; unreachable flips the endpoint to 503; a missing bridge fails closed) and a report-only `provisioner` probe of `{sandbox.provisioner_url}/health` that never changes the status code, since every replica shares one provisioner. The provisioner URL is snapshotted on app.state at startup. - A probe that overruns the endpoint deadline is now the only one marked unreachable; finished verdicts are kept. - The public probe gate is one lock per probe kind, so one request's probes still run concurrently while a thundering herd opens at most one probe connection per kind per process. - Tests: bridge ping cases, stream-bridge/provisioner probe cases, verdict and deadline cases, and the first route-level /health/ready tests via TestClient. - Docs: gateway AGENTS.md, CONFIGURATION.md multi-instance notes, Helm README and probe comment, Compose healthcheck comment. * docs(changelog): note the readiness probe fix (#6447) * fix(gateway): apply the sandbox proxy policy to the provisioner probe Review follow-up for #6447. - The provisioner readiness probe built its httpx client with the default trust_env=True. httpx 0.28 treats CIDR entries in NO_PROXY as host patterns rather than subnet bypasses, so with HTTP_PROXY set and NO_PROXY=10.0.0.0/8 a private provisioner that the requests-based sandbox calls reach directly would have been probed through the proxy and reported unreachable on every check. The probe now reuses `sandbox_http_trust_env`: loopback, private, link-local and cluster-local addresses bypass the proxy, external hosts keep the environment's proxy settings. - Pin the liveness/readiness separation with a route test: `GET /health` stays 200 while the stream bridge and database are unreachable and `/health/ready` is 503, so a Redis blip can never become a restart loop.	2026-10-08 06:56:33 +08:00
yu1128-L	a4427625cf	fix(skillscan): detect fine-grained PATs and Google API keys, scan .zsh (#6423) ... - secret-cloud-token: add the github_pat_ and AIza families, matching the canonical PII detector. - _is_shell_path: treat .zsh by suffix, so a missing shebang or a rename can no longer bypass every shell rule. - Sync the same two patterns into _EGRESS_SECRET_PATTERNS so the IM egress scrubber stays in lockstep with skillscan. - Regression tests for all of the above. Co-authored-by: yu1128-L <296164533+yu1128-L@users.noreply.github.com>	2026-10-07 21:16:46 +08:00
Daoyuan Li	734f9e0e92	fix(runtime): omit leading reasoning from run summaries (#6419)	2026-10-07 17:20:11 +08:00
王一帆	1de47b56ed	fix(skillscan): detect modern sk API tokens (#6394) ... * fix(skillscan): detect modern sk API tokens * fix(skillscan): skip placeholders and align notification redaction	2026-10-07 17:10:45 +08:00
NanPan	1d3e68363c	fix(integrations): drain Lark install across cancellation (#6408) ... * fix(integrations): rebase cancellation drain onto latest main * style(integrations): satisfy ruff formatter	2026-10-07 17:02:23 +08:00
hataa	0032579017	feat(authz): admin role-assignment API for configured custom roles (#4063 gap 2) (#6382) ... * feat(authz): admin role-assignment API for configured custom roles (#4063 gap 2) The RBAC provider accepts arbitrary configured role names (guest, ...), but nothing could assign them to real users: User.system_role was pinned to Literal["admin", "user"] at the API layer while the DB column stayed a plain String(16) for exactly this future, and zhfeng's #3462 audit listed the missing assignment surface as gap 2 — custom roles were declarable in YAML but unreachable for authenticated web users. - User/UserResponse.system_role widens to a non-empty string; whether a role is *assignable* is the admin API's contract, not the model's. - RbacAuthorizationProvider exposes known_roles; the Gateway's new assignable_role_names() unions the built-ins with the provider's configured role names (custom providers: built-ins only). - New admin-only router /api/v1/admin/users: GET lists users with their role; PATCH assigns — role validated against assignable names (an unknown role would silently fall through to default_role on every decision), 404 for missing users, and the last remaining admin cannot be demoted (bootstrap lockout protection). Enforcement is unchanged: the assignment only changes which role the principal carries; the @require_permission route guards and runtime provider decisions remain the single enforcement points. - SQLite repository gains list_users (ordered oldest-first). Tests: router guard/422/404/409/no-op/happy-path, last-admin invariant (both directions), assignable names union, principal carries the configured role; the two old Literal-rejection contract tests updated to the new contract (custom role representable; empty string still rejected). * fix(auth): widen the frontend user schema for custom roles (review-lessons catch) The role-assignment API's review-lessons sweep found the one consumer class the implementation had not enumerated: the FRONTEND parses /me with a strict userSchema whose system_role was z.enum(["admin", "user"]) — a user assigned a provider-configured custom role (guest) would fail userSchema.parse in server.ts and break the auth flow before rendering anything. - types.ts: system_role widens to z.string().min(1), kept in lockstep with the backend model (min_length=1). All existing consumers compare === "admin", so any other value is simply non-admin — no behavior change for admin/user. - server.test.ts: contract tests — custom role parses verbatim; empty string still rejected. - config.example.yaml: the authorization comment now says custom roles become reachable via PATCH /api/v1/admin/users/{id} and that a declared-but-unassigned role grants nothing. * fix(auth): commit the admin_users router, drop the stale type-ignore, document the surface Review catch on #6382: the router module was never staged — app.py and the tests import it, so the pushed branch could not boot (ImportError in create_app). The local tree kept it as an untracked file, which is why every check passed before the push. - Actually commit app/gateway/routers/admin_users.py. - _row_to_user: drop the now-stale '# type: ignore[arg-type]' on system_role — the model field is a plain string now (keep the comma). - README: the authorization paragraph now mentions the admin role-assignment surface (GET/PATCH /api/v1/admin/users, admin-only, last-admin demotion protected, declared-but-unassigned grants nothing). - server.test.ts import-order lint fix from the frontend sweep. * fix(auth): field-scoped role writes close the demotion-undo race Review round 2 on #6382 — three findings, one design: - [P1] update_user copied system_role from the caller's account snapshot, so a password change that read the user as admin could restore a role concurrently revoked by the demotion route (stale-snapshot write-back). Account writes are now field-scoped against each other: update_user is the credential/profile writer (never touches the role, mirrors the row's current role back), update_system_role is the only role writer (single-column, never touches credentials or token_version). - The last-admin lockout check moved inside the role write's serialized transaction: count-then-write across two sessions let two concurrent demotions of the only two admins both pass. Same idiom as create_first_admin — BEGIN IMMEDIATE on SQLite, pg_advisory_xact_lock on a distinct key on Postgres, raise on unknown dialects. - UserNotFoundError from the racing-delete window maps to the route's 404 instead of a 500. Tests 11->12: real-repo regression covering the P1 interleaving (demotion lands -> stale credential snapshot writes -> role stays revoked, credentials applied), field isolation both directions, and the last-admin invariant raised from inside the write with the row intact. Mutation-verified: restoring the role write-back in update_user fails it. * style(auth): format the server auth tests * fix(tests): migrate the personal-MCP demote revocation to update_system_role The role-write field-scoping (66e2cec23) made update_user a credential/profile-only writer, so the demote branch of test_revocation_blocks_discovery... silently no-oped and CI failed on all four shards (assert 2 == 1 — the role never changed). - The demote now goes through update_system_role, the sole role writer. - The fixture gains a second admin: the revocation test demotes its sole synthetic admin, which the new last-admin lockout guard correctly blocks — a second admin keeps the scenario legal without weakening either invariant. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-07 14:59:16 +08:00
NanPan	aa1472625d	fix(gateway): bound scheduled task shutdown (#6409) ... * fix(gateway): rebase scheduler shutdown bound onto latest main * style(gateway): format scheduled task shutdown --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-07 14:46:23 +08:00
Totoro	35cdcab1c5	feat(scheduled-tasks): signals, honest notices and fair queueing for server-started runs (RFC #6340, 2/2) (#6393) ... * feat(scheduler): lifecycle rules, goal/limit parity and coded errors for scheduled tasks - Migration 0031: nullable scheduled_tasks.unmet_streak_after_seq (internal streak boundary) and stop_condition (the user's stop rule, own column). - Stop rule is normalized (stop_rule.py) and appended only at launch; the stored prompt never contains it. Wording adapts when scheduler.tool_enabled is off. - Willem 1: page-created tasks get goal evaluation, <standing_notes>, the previous-run reference and own-schedule stop; request_stop and the scheduled capability no longer require an origin conversation. - Repository: single reactivation choke point raising ScheduledTaskLimitsExhausted; streak boundary moves on goal/prompt/stop condition/note changes (not on resume); goal-check failures neither count nor reset the streak; pause of a finished task returns "finished"; trials on a paused task keep the host pause marker. - New repository reads: automatic_runs_used_for, active_run_status_for, list_manageable_from_thread, thread_relation/thread_run on thread tasks, task_ids_for_thread, run_number, and run_number/total_tokens/summary on run history rows. - REST: goal/max_runs/end_at/stop_condition on create and PATCH (null clears, naive end_at = task timezone), resume recomputes from now with an optional renewal body, once_time_passed, task_finished, limits_exhausted, scheduler_not_running on create, trigger returns outcome/existing/thread_id, task responses add automatic_runs_used and active_run_status. - Coded errors {code, message, params} for routes, shared validation and the chat capability (scheduled_task_errors.py), pinned by contracts/scheduled_task_errors_contract.json; goal notes contract v2 with check_failure_codes, scheduled_origin_key and host_run_errors (host_notes.py). - /api/features adds scheduled_tasks {available, running, tool_enabled, min_interval_seconds}; ScheduledTaskService.is_running. - Docs: six README scheduler sections, API.md scheduled tasks section (breaking error shape), CONFIGURATION.md, AGENTS notes, CHANGELOGs. - Tests: migration 0031, stop rule, error contract, run listing, lifecycle over HTTP, repository, service and capability cases; updated tests for the new error shape, finished-task pause and head revision. * feat(scheduler): conversation update/resume, run-conversation authority and readable launches - schedule_task: update and resume actions, stop_condition and clear_fields parameters, plain parameter types (value rules come back as coded results), rewritten docstrings for schedule_task and stop_scheduled_task. - Capability: update/resume share the REST validation and error codes; interactive turns in a task's run conversation may manage that task; scheduled runs keep only own-stop; grants require a running scheduler. - Results: compact JSON-safe task views with local times, display card/text, last run in list, timezone_source/browser_timezone, now_local; no ISO, user, lease or origin fields; stop_instructions removed. - Timezone: explicit > browser (context.client_timezone, validated in start_run and never forwarded to the run config) > not needed for intervals and offset run_at > timezone_required. - Trial gate accepts natural direct requests after acknowledgements and particles; trial results report thread_id and existing. - Scheduled launches: stable message id scheduled-<task_run_id>, server-owned deerflow_scheduled_origin metadata with the user-language parts, run thread title for fresh-thread tasks. - Worker records goal continuations in the verdict; lead prompt language rule covers stored task text and scheduled runs. - Docs: six READMEs, CONFIGURATION, API, runtime/tools AGENTS, CHANGELOGs. * feat(frontend): scheduled-task core types, formatting, errors and glossary - throwGatewayApiError now throws GatewayApiError (status, code, params, rawMessage); message stays the string detail or detail.message - scheduled-task types gain stop_condition, automatic_runs_used, active_run_status, origin/notes, run_number/total_tokens/summary, thread relation, trigger result, renewal and scheduled origin; isTaskBusy and hasActiveRun helpers - api: fetchScheduledTask, resume with optional renewal body, typed trigger result and update payload with null clears - hooks: polling at 3 s while a run is active (list, thread list, run history), useScheduledTask with live gating and final 404, useInView, localized error toasts; run history refreshes tasks when a run finishes - new pure modules: errors.ts (contract code to localized copy), format.ts (relative task times, viewer time, display zone), status.ts, actions.ts, run-error.ts; describeTaskSchedule in cron.ts; goal-outcome adds unchecked goal checks, describeTaskOutcome and parseStopRunId - features: scheduled_tasks block with defaults when missing - buildRunContext sends client_timezone - titleOfThread takes a localized untitled label; breadcrumb names scheduled tasks and agents; reference chips use the localized untitled label - schedule input: shared browserTimeZone, labelled selects, aria-pressed type toggles, interval minimum from the hint template - i18n: all PR1 scheduled-task keys in en-US and zh-CN, glossary fixes, recipe instructions moved into i18n - e2e mocks follow the new task, trigger, resume, thread-task and features shapes; expectNoRawIdentifiers helpers for e2e and DOM tests - tests for errors, format, cron, status, actions, goal outcome, run errors, hooks, run context, thread titles and features; scheduled e2e copy updated * feat(frontend): list-first scheduled tasks page with outcomes and editable goals - page.tsx is now a thin composition of components/workspace/scheduled-tasks: status tabs (All/Active/Paused/Finished) and search over the task list, ?task_id= deep link with router.replace on selection, ?thread_id= chip with Show all, empty state, scheduler-off notice and unavailable state - task list rows show the schedule in words and one status line (next run, running now, paused by agent, auto-paused, finished by its cap) - task detail: status badge, actions from availableActions with reasons, More actions menu (Duplicate, Copy task ID, Delete), outcome notice, Runs / Stops when / Each run's goal / Does / Notes from chat / History, origin chat link; success toasts for every action - run rows: run number or Trial run, summary, goal and assumption badges, continuations, tokens, Open chat link; raw errors and the evaluator reason only behind Details - create/edit/duplicate dialog with goal, stop condition, safety caps and advanced agent/context options; PATCH sends only changed fields, null clears a cap - renew dialog raises or removes caps and resumes in one request; a limits_exhausted Resume opens it - removed i18n keys the old page used; added feedback.resumedNoTime - recorded en-3 and zh-1 page fixtures; scheduled e2e specs rewritten for the new page; DOM tests for the detail and the form dialog - CHANGELOG entries and the frontend AGENTS.md scheduled-task note * feat(frontend): live schedule card, run conversation provenance and header entry - schedule_task results (create, update, pause, resume, trial, delete) become an assistant:scheduled-task message group rendered as a live card: schedule, next run, stop condition with the safety cap, goal, where results go, Run once now, Pause/Resume and Open task; the card polls the task only while it is on screen and shows deleted, scheduler-off and limits-exhausted states - one card per task per assistant turn; the card group is not a turn boundary for usage, branching, editing, outline or skill attribution - a human message with deerflow_scheduled_origin stays a human group with scheduledOrigin and renders as a "Scheduled run / Trial run" block with the task instructions, stop condition and notes collapsed; the launched text is never shown and the message is not editable - readable step labels for schedule_task actions and stop_scheduled_task - ThreadScheduledTasksButton replaces the header link: hidden without tasks, shows the count, links to the task (or the chat filter), and a run's chat links to its task - recorded en-3 / zh-1 chat and run-thread fixtures; chat-card and run-thread e2e specs; unit and DOM tests for parsing, grouping, turn boundaries, card, run block, header button, step labels and reconnect hydration - i18n: header.countLabelOne added, unused card.next removed; CHANGELOG and frontend AGENTS.md notes * fix(scheduler): address verification findings Move the scheduled-task lifecycle guidance from backend/AGENTS.md into the persistence guide and leave a one-line pointer, so the effective AGENTS.md chains for agents/middlewares, sandbox and subagents stay under the 98304-byte hard limit enforced by scripts/check_agent_guidance.py in lint-check. * fix(scheduler): address review findings * fix(gateway): no-transform on SSE responses All four text/event-stream responses (thread run create stream, join, existing-run GET/POST stream, stateless create stream) now take their headers from app/gateway/sse_headers.py and send Cache-Control: no-cache, no-transform, so compressing proxies such as Next's rewrite proxy stop buffering streams. Content-Location and X-Accel-Buffering are unchanged; scheduled and MCP-notification runs keep stream_mode=None. Tests pin the headers on every SSE route and fail on a literal no-cache header left in routers. Docs: API.md SSE headers note, CHANGELOGs. * feat(scheduler): per-owner run cap and fair queue selection New scheduler.max_concurrent_runs_per_user (default 2, 0 = off, effective min(cap, max_concurrent_runs)) caps launching/running scheduled runs per task owner. claim_queued_run checks it right after the global count under the same budget lock, so it is atomic across workers and Pods. list_queued_runs ranks same-thread FIFO heads per owner with ROW_NUMBER() OVER (PARTITION BY owner) and orders the batch by that rank, so the drain is owner-fair even with the cap off; owners at their cap drop out before the batch limit. Orphan rows (task deleted while queued) are never held back by the cap. Gateway lifespan passes the startup value; the service constructor default stays 0. Docs: config.example.yaml (config_version 54), CONFIGURATION.md, the six READMEs, backend AGENTS.md, CHANGELOGs (behavior change flagged). The live-task quota is untouched. * feat(scheduler): durable lifecycle events for the originating chat When a chat-created schedule is paused by the agent, auto-paused or finishes, finalization now reports task_stopped / task_paused / task_finished, only on a live -> paused/finished transition. The new finish_task_at_end_condition replaces the three inline "mark completed" blocks (admission rejected as ended, claim-time skip, complete_if_ended), so every site emits exactly once. The scheduler's finalization observer is always installed. It writes scheduled_task_events rows for the originating chat in the same transaction as the state change, deduplicated on (task_id, anchor, event), with a title snapshot, stop condition, run number, last run outcome and the chat's newest run as placement anchor. Lookups fall back on bad stored data; only database errors propagate. Manual trials drop only run_* events. The IM step keeps PR1's selection until B4. New GET /api/threads/{thread_id}/scheduled-task-events (owner check, caller's rows, oldest first); rows survive task deletion and go with the chat. Migration 0032_activity_and_task_events adds the events table plus the run-origin column/index and read-state tables used later, each object guarded on its own. Contract scheduled_goal_notes v3 pins the lifecycle vocabulary. Docs: API.md, migrations chain, backend AGENTS.md, six READMEs, CHANGELOGs. * feat(scheduler): honest, localized and self-contained IM notices Every scheduled-task IM notice is now enqueued by the finalization observer in the transaction that records the outcome, one message per occurrence (task_stopped > task_paused > task_finished > run_failed > run_unmet > run_completed; a once task sends only its run event). The merged auto-pause replaces the separate unmet + pause messages, agent stops and finishes now notify, and recovery-finalized runs notify exactly once. Idle finishes use a deterministic idle: key derived from the lifecycle anchor. The old non-transactional enqueue in handle_run_completion is removed. New app/channels/capabilities.py holds CHANNEL_CAPABILITIES with a proactive_notifications flag (adds the missing qq entry); only push-capable providers (WeCom) get rows, /api/channels/providers returns the flag, and the worker ends legacy rows for other providers as terminal failed. New app/scheduler/notification_text.py renders en-US/zh-CN text: title, what happened (plus the last run's outcome), the tasks page's one-line run summary (redacted) when the agent replied, and a closing line. No IDs, no links, no public_base_url. Locale is the owner's new `locale` preference, else the new channel_connections.notification_locale (default en-US). Docs: config.example.yaml (config_version 55), CONFIGURATION.md, API.md, channels AGENTS.md, six READMEs, CHANGELOGs (behavior change flagged). * feat(gateway): thread origin, activity feed and read markers for server-created threads Runs started by the server for a user (scheduler, IM channels, GitHub agents, extension handles, MCP notifications) now carry a server-owned metadata.deerflow_origin {kind, provider?, namespace?} (new harness module deerflow.runtime.run_origin, pinned by contracts/thread_origin_contract.json). It is stamped only from request.state.run_origin or by the internal channel caller; run admission drops client copies from both metadata and config.metadata, and thread create/patch strip it. RunRepository derives runs.origin_kind on put and on create_thread_operation_atomic (agent runs only), and gains latest_change(). New ThreadReadRepository keeps a per-user, never-decreasing read position (thread_read_markers) and a per-user read clock (thread_read_versions). POST /api/threads/{id}/read marks a thread read, thread search items carry unread, and thread delete removes the markers. GET /api/thread-activity pages the caller's run changes over the run-change clock, returns only threads changed by server-originated runs plus read_version, and 503s without SQL; /api/features reports thread_activity.available. Docs: API.md, gateway AGENTS.md (condensed to stay under its budget), CHANGELOGs. * fix(scheduler): adapt PR2 to PR1 follow-ups PR1 moved the scheduled-task lifecycle rules out of backend/AGENTS.md into the persistence guide and grew the sandbox AGENTS.md chain to within 267 bytes of its hard limit. The per-owner queue-fairness detail now lives in the persistence guide next to the lifecycle rules (backend/AGENTS.md keeps the cap and a link), so check_agent_guidance passes again. PR1's goal-outcome unit test pinned scheduled_goal_notes_contract version 2; PR2 bumps it to 3 (lifecycle vocabulary only, the v2 keys are unchanged). * fix(scheduled-tasks): polish from live acceptance - zh schedule wording: an interval of one unit reads 每分钟 / 每小时 / 每秒, and a saved interval of whole days reads 每天 / 每 2 天 (Every day / Every 2 days) instead of 每 1 分钟 or 每 24 小时; several units keep the number - zh spacing: 已于{time} 满足 and 在{time} 的运行中 now leave a space between the interpolated time and the Chinese after it; a copy test guards every scheduled-task zh string against a placeholder glued to Chinese - run summary: when the first line of the final reply only leads in to a list (ends with ":" or "："), the list items follow it as plain text (bullets, numbering, checkboxes, bold, code and links stripped), joined with "；" for CJK text and "; " otherwise, within the 160-character cap - a schedule_task result (create, update, pause, resume, trial, delete) that arrives in a chat invalidates that chat's task list, the tasks list and the named task, so the header button and cards update without waiting for the idle poll; results already in the loaded history do not refetch - e2e and unit fixtures are now the live acceptance recordings (DeepSeek Flash, demo data, fictional names): live-weekday.json (create, trial, edit, pause, resume in one zh chat) and live-minute.json (per-minute chat, run 1 and run 2, paused by the agent), fetched with GET from the demo Gateway and trimmed; the hand-shaped en-3 / zh-1 fixtures are removed and the chat-card, run-thread and tasks-page specs run in both locales over the recorded data * docs(changelog): reference #6378 for the scheduled-tasks entries * docs(agents): shorten the scheduled-task pointer to stay under the guidance limit * test(scheduled-tasks): pin the live takes to their recorded time zone The live fixtures were recorded in Asia/Shanghai, and an interval task reads in the viewer's zone, so the 16:48 assertions failed on UTC CI runners. Pin the browser zone in the two live-take e2e specs and the zh live-take unit test. * feat(frontend): thread origin, activity polling, read markers and task events core Frontend core for server-created threads and schedule lifecycle events (PR2 F1); the sidebar markers (F2) and the chat event line (F3) build on it. - core/threads/origin.ts: threadOriginOf reads metadata.deerflow_origin, then channel_source (github -> GitHub origin), then a legacy scheduled_task_id; key and kinds pinned to contracts/thread_origin_contract.json. labelOfThreadOrigin and the now exported labelOfChannelProvider(provider, t) use the new localized threads.origin.providers names (飞书, 企业微信, ...), with the English map (gaining GitHub) only as the fallback. - core/threads/activity.ts: useThreadActivity polls /api/thread-activity every 15 s (focus refetch, never in the background, off unless features.thread_activity.available). The first response only seeds the cursor; server-origin threads, a truncated page or a higher read_version invalidate the thread lists, a scheduled thread also ["scheduled-tasks"]; an invalid cursor re-seeds. useMarkThreadRead debounces POST /read by 1 s, skips a thread whose cached unread is false, patches the search and infinite caches optimistically and stores the returned read_version so a tab's own read does not refetch its lists. AgentThread gains unread. - core/scheduled-tasks/events.ts: ScheduledTaskEvent, the events query (["scheduled-tasks","thread-events",id], one fetch per saved chat, not gated on the task list so a deleted task's lines stay, refetched when a task of the chat changes status or finishes a run), describeTaskEvent (en/zh copy, title and condition as segments, last-run suffix, See that run / Open task) and placeTaskEvents (end of the after_run_id turn, else the tail, ordered by created_at); lifecycle names pinned to contract v3. - features: thread_activity (default unavailable); channels: proactive_notifications on providers. - Locale sync: the I18nProvider reports the UI language and a signed-in preference session saves it as the new `locale` preference when the account's differs (and on every switch), so IM notices follow the UI language; nothing is written with auth disabled. - i18n: threads.* (unread, origin labels, provider names), scheduledTasks.events.*, history.waitingForSlot (now shown for queued run rows), channels.scheduledUpdates.*. - e2e mocks: thread activity feed and controller, POST /read, the events route, providers with proactive_notifications, search unread, features thread_activity (off by default). Preference e2e mocks return the UI locale so they keep asserting only their own edits. - Docs: frontend AGENTS.md, CHANGELOGs. * fix(scheduled-tasks): keep untouched end times and drop a chat filter the new task is not in - The edit, duplicate and renew dialogs keep a stored end time's instant while its field still shows it. A minute-precision wall value cannot keep seconds or name the later 01:30 of a DST fall-back, so a title-only edit moved the cap an hour earlier, and raising the run limit re-sent the end time without its seconds. - Creating or duplicating a task from a chat's task view drops the chat filter when the new task does not belong to that chat, instead of showing "This task isn't one of this chat's tasks". * feat(frontend): origin markers and unread state in the thread lists Server-created threads (PR2 F2) now say who created them and whether they are new, in the sidebar and on the Chats page, and reach an open sidebar without a reload. - ThreadOriginIcon (thread-channel-source.tsx): clock for a scheduled run, the provider mark for IM threads, the GitHub mark (new in ChannelProviderIcon) for GitHub threads, a puzzle piece for extensions; the localized "Scheduled run" / "From Feishu" / "From GitHub" / "From an extension" label is its accessible name and tooltip. ThreadChannelIcon stays exported as a wrapper, and the provider chip tooltip is localized (no more "Feishu channel"). - Unread dot after the title (aria-hidden dot plus sr-only "Unread"); the row aria-label becomes "{title}, unread" / "{title}，未读". Never shown for the open thread. - WorkspaceSidebar mounts useThreadActivity once. - useMarkOpenThreadRead (components/workspace/chats): the default and custom-agent chat pages mark the thread read once its metadata has loaded, when its cached unread flips to true while open, when the tab becomes visible, and from onFinish (a send or a joined run ended). Each trigger goes through useMarkThreadRead, so it is debounced and a no-op while the cached unread is false. - Tests: thread-origin-icon and recent-chat-list DOM tests (en/zh, active row, no raw identifiers), use-mark-open-thread-read DOM tests, e2e thread-activity.spec.ts (new scheduled run appears unread within one fake-clock poll without a reload, opening it posts /read and clears the dot, a read on another device clears it, IM and GitHub markers, zh labels, the Chats page, no polling when unavailable); thread-history.spec.ts now finds the localized origin icon. - Docs: frontend AGENTS.md, CHANGELOGs. * feat(frontend): schedule event line in the originating chat and channel notice support The chat that created a schedule now says when the schedule paused or ended, and the channel cards say which apps receive scheduled task updates (PR2 F3). - ScheduledTaskEventLine (mockup m2, marker 4): a dashed, muted row with the describeTaskEvent text (title in <strong>, stop condition clamped to one line with the full text in its tooltip, last-run suffix), the time via formatTaskTime and a right-aligned "See that run" (run chat) or "Open task" link. PauseCircle for paused, CircleCheck for finished and once-done, CircleX for once-failed. role="note", aria-label "Scheduled task update" / "定时任务通知", data-task-id and data-event-id only. - MessageList takes scheduledTaskEvents and renders placeTaskEvents output through a new VirtualMessageList.renderAfterGroup, so each line sits at the end of its after_run_id turn inside the group's measured row (also when the list virtualizes); lines with nowhere to go render at the tail. - Both chat pages load useThreadScheduledTaskEvents (not gated on the task list, so the lines stay after a task is deleted). The custom-agent page passes its agent so "See that run" opens the run on that agent's route. - ChannelScheduledUpdates: "Scheduled task updates: sent here" / "... not available for this app yet" (定时任务通知：会发送到这里 / 此应用暂不支持) on the Settings provider cards and under each sidebar channel row; nothing when an older backend does not report proactive_notifications. - e2e mock controller: setScheduledTasks. - Tests: scheduled-task-event-line and channel-scheduled-updates DOM tests (every kind in en and zh, hrefs, clamp, no raw identifiers, Chinese title), MessageList placement DOM tests; e2e scheduled-task-chat-events.spec.ts (the line appears with the card's "Paused by agent" without a reload, See that run opens the run chat, anchored vs tail placement, two events in time order, the line survives task deletion and Open task shows the task is gone; en-3 and zh-1) and channels.spec.ts (WeCom sent here, Feishu not yet; en and zh). - Docs: frontend AGENTS.md, CHANGELOGs. * fix(scheduled-tasks): tie pause notices to the pause they describe - Paused by agent links and times only the run named in last_error. When that run is not loaded, the notice shows no link and the task's own time instead of an earlier run that also asked to stop. - The outcome notice reads the latest history page whichever page is shown, so browsing older runs no longer swaps the auto-pause reason and "Open latest run" to an earlier miss. It shares that page's request. * fix(scheduler): address PR2 review findings - Event lines: hold an event whose anchor run is on an unloaded history page instead of placing it at the bottom (hasMoreHistory); tail fallback only for fully loaded (branched/pruned) history or no anchor. - Idle-finish anchor follows its reason: end:<iso> only for an end_at finish, seq:<n> otherwise, so a later end-time finish is not deduplicated away by an earlier max_runs finish. - Observer takes FOR SHARE on the originating threads_meta row, so a racing thread delete cannot leave an orphan event line. - One taskPagePath (core), re-exported by the card. - Notification locales derived from NotificationLocale; /preferences uses it. - IM notices drop generic reasons (goal_not_met_yet, unknown) instead of repeating the sentence. - Localized provider names on Settings cards, sidebar rows and setup dialog. - zh event lines: no space after a Chinese title (Latin-aware gap). - Unread row label keeps the origin marker; chats page keeps the time as a description. - Sidebar shows the scheduled-updates line only for connected apps; Settings says "available after you connect" for unconnected push apps. - Event line keeps a real space before the time. * fix(scheduled-tasks): three lifecycle gaps found while re-checking review classes - The edit form compares a cron in the form its schedule input emits, so an untouched "0 09 * * 0,6" is not re-sent as "0 9 * * 6,0" and a title-only edit no longer re-arms or refuses a finished task. - Chat resume asks for a timezone, as update does, when a naive end_at would land in the UTC placeholder of a zone-free task. - Re-arming a task clears a host pause marker, as resume does, so a later manual pause no longer reads as "Paused by agent". * test(scheduler): consolidate PR2 backend test setup - Fold the repeated task, origin-chat and observer setup of the lifecycle-event repository tests into one lifecycle_task builder. - Build the per-owner-cap services through one _capped_service builder that keeps every cap explicit at the call site. - Table the five SSE route header checks into one parametrized test with the same routes, bodies and Content-Location expectations. - Reuse bind_wecom and hoist repeated local imports in the event tests. Every case and assertion is kept; collected cases are unchanged. * test(frontend): consolidate PR2 thread activity and origin test setup Extract shared builders and helpers in the frontend tests PR2 adds, with every case, input and assertion kept: - activity.test.ts: seededClient/apply helpers and one LIST_KEYS constant replace the per-test seed, spy and apply boilerplate. - mark-read.dom.test.tsx: newClient() and advance() replace the repeated QueryClient wrapper and fake-timer act blocks. - origin.test.ts: the English and Chinese label checks become tables; the no-English-name check now runs on every Chinese row. - thread-activity.spec.ts: a scheduledRun() builder replaces four inline copies of the scheduled run thread. - channels.spec.ts: the PR2 block uses setLocaleCookie and one card helper. Collected cases are unchanged (unit 211, e2e 60); no test was removed. * fix(scheduled-tasks): keep the notice's latest-runs query from refreshing older pages useLatestScheduledTaskRuns kept React Query's default refetch on mount, focus and reconnect, so going offline and back while an older history page was shown fetched the latest page again. Refreshing stays with the history, which refreshes the latest page only while it is shown. * fix(scheduler): two gaps found in live acceptance - A fresh scheduled run thread is named when it launches. The worker copied the title to the thread list only when the run ended, so the sidebar, which now shows the new run thread at once, listed it as untitled while it ran. - A task capped at one run finishes with "its one run is done" / "唯一一次运行已完成" in the chat event line and the IM notice, instead of "all 1 runs are done". * test(scheduled-tasks): let the viewer's time carry its own day label Between 16:00 and 24:00 UTC, UTC and Asia/Shanghai are on different days, so the run prompt shows "Tomorrow 01:00 · Today 09:00 your time" and the fixed "01:00 · 09:00 your time" assertion failed depending on the hour. * test(scheduler): expect the one-run finish copy in service notices * fix(gateway): create a scheduled run thread with its title Pre-setting the name after start_run raced the thread row, which the run worker creates asynchronously: live, one of two run threads still reached the sidebar untitled. Run admission now creates a new thread with the title its run input carries, which the worker would copy only at run end. * docs(changelog): reference #6393 for the scheduled-task signal entries * fix(scheduled-tasks): route event-line run links by the agent that ran them The originating chat's agent was used for "See that run", but a task's agent can change after the chat created it, so the link could open the run chat on another agent's route. Lifecycle events now record run_agent_name, the task's agent when the run finished (edits are refused while a run is active), and the line routes by it. * fix(scheduled-tasks): load up to the route's maximum of chat event lines The chat loads its lifecycle events once, and the route's default of 50 would silently drop the oldest lines of a chat with many schedules. Ask for the maximum, 200. * fix(threads): keep activity reads and the first cursor in step with the lists - Accepting the first activity cursor refreshes the thread lists once. The lists load on their own, possibly before a run the seed already counts, and later polls start after it, so such a thread never appeared. - A local read whose returned read clock jumps past that one read also covers reads on other devices; the lists are refreshed instead of the clock silently skipping those threads' stale unread dots. - An invalid cursor re-seeds through the same path, so it refreshes once. * docs(agents): bring the middlewares guidance chain back under the hard limit #6378 and #6363 each fit the budget, but together the middlewares AGENTS.md chain on main is 98,425 bytes, 121 over the 98,304 hard limit, so Lint Check fails on main. Move the scheduled-task recovery, launch-update and queue-timeout rules from backend/AGENTS.md into the persistence guide's lifecycle section, which backend/AGENTS.md already points to. The chain is now 98,067 bytes. * fix(helm): bump the chart's config_version to 55 config.example.yaml moved to 55 in this PR, so the Helm chart's validate-chart drift check failed. The chart's embedded config needs no field changes: the new scheduler and channel keys have defaults. --------- Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-07 10:22:15 +08:00
Hyeonsang Cho	3f73801086	fix(channels): give channel run input messages an id (#6401) ... * fix(channels): give channel run input messages an id Channel runs sent their human message without an id. The Gateway stores run input as sent, so the run record kept it id-less, while add_messages gave the checkpoint copy a fresh uuid. When a web client opens the thread while the run is still going, its reconnect hydration rebuilds the input from both copies and matches them by id, so the user's message showed up twice until the run finished and the view fell back to the checkpoint. _human_input_message now stamps a uuid on every message it builds, so the run record and the checkpoint carry the same id. It covers both channel run paths: regular turns and the coalesced follow-up drain. * docs(changelog): reference #6401	2026-10-07 08:44:43 +08:00
NanPan	8598687d3d	fix(channels): keep config reload publication under lifecycle lock (#6390) ... * fix(channels): keep config reload publication under lifecycle lock * test(channels): prevent stale config publish after cancellation * test(channels): exercise real stale reload write * test(channels): harden cancelled config reload regression --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-07 08:26:53 +08:00
NanPan	8c0cc39ad1	fix(wechat): drain poll-state persistence across cancellation (#6389) ... * fix(wechat): retain cursor persistence across cancellation * fix(wechat): drain expired auth-state persistence * fix(wechat): drain the complete token expiry transition --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-07 08:18:55 +08:00
Totoro	2dd2e5415c	feat(scheduled-tasks): finish the user-facing side of conversation schedules (RFC #6340, 1/2) (#6378) ... * feat(scheduler): lifecycle rules, goal/limit parity and coded errors for scheduled tasks - Migration 0031: nullable scheduled_tasks.unmet_streak_after_seq (internal streak boundary) and stop_condition (the user's stop rule, own column). - Stop rule is normalized (stop_rule.py) and appended only at launch; the stored prompt never contains it. Wording adapts when scheduler.tool_enabled is off. - Willem 1: page-created tasks get goal evaluation, <standing_notes>, the previous-run reference and own-schedule stop; request_stop and the scheduled capability no longer require an origin conversation. - Repository: single reactivation choke point raising ScheduledTaskLimitsExhausted; streak boundary moves on goal/prompt/stop condition/note changes (not on resume); goal-check failures neither count nor reset the streak; pause of a finished task returns "finished"; trials on a paused task keep the host pause marker. - New repository reads: automatic_runs_used_for, active_run_status_for, list_manageable_from_thread, thread_relation/thread_run on thread tasks, task_ids_for_thread, run_number, and run_number/total_tokens/summary on run history rows. - REST: goal/max_runs/end_at/stop_condition on create and PATCH (null clears, naive end_at = task timezone), resume recomputes from now with an optional renewal body, once_time_passed, task_finished, limits_exhausted, scheduler_not_running on create, trigger returns outcome/existing/thread_id, task responses add automatic_runs_used and active_run_status. - Coded errors {code, message, params} for routes, shared validation and the chat capability (scheduled_task_errors.py), pinned by contracts/scheduled_task_errors_contract.json; goal notes contract v2 with check_failure_codes, scheduled_origin_key and host_run_errors (host_notes.py). - /api/features adds scheduled_tasks {available, running, tool_enabled, min_interval_seconds}; ScheduledTaskService.is_running. - Docs: six README scheduler sections, API.md scheduled tasks section (breaking error shape), CONFIGURATION.md, AGENTS notes, CHANGELOGs. - Tests: migration 0031, stop rule, error contract, run listing, lifecycle over HTTP, repository, service and capability cases; updated tests for the new error shape, finished-task pause and head revision. * feat(scheduler): conversation update/resume, run-conversation authority and readable launches - schedule_task: update and resume actions, stop_condition and clear_fields parameters, plain parameter types (value rules come back as coded results), rewritten docstrings for schedule_task and stop_scheduled_task. - Capability: update/resume share the REST validation and error codes; interactive turns in a task's run conversation may manage that task; scheduled runs keep only own-stop; grants require a running scheduler. - Results: compact JSON-safe task views with local times, display card/text, last run in list, timezone_source/browser_timezone, now_local; no ISO, user, lease or origin fields; stop_instructions removed. - Timezone: explicit > browser (context.client_timezone, validated in start_run and never forwarded to the run config) > not needed for intervals and offset run_at > timezone_required. - Trial gate accepts natural direct requests after acknowledgements and particles; trial results report thread_id and existing. - Scheduled launches: stable message id scheduled-<task_run_id>, server-owned deerflow_scheduled_origin metadata with the user-language parts, run thread title for fresh-thread tasks. - Worker records goal continuations in the verdict; lead prompt language rule covers stored task text and scheduled runs. - Docs: six READMEs, CONFIGURATION, API, runtime/tools AGENTS, CHANGELOGs. * feat(frontend): scheduled-task core types, formatting, errors and glossary - throwGatewayApiError now throws GatewayApiError (status, code, params, rawMessage); message stays the string detail or detail.message - scheduled-task types gain stop_condition, automatic_runs_used, active_run_status, origin/notes, run_number/total_tokens/summary, thread relation, trigger result, renewal and scheduled origin; isTaskBusy and hasActiveRun helpers - api: fetchScheduledTask, resume with optional renewal body, typed trigger result and update payload with null clears - hooks: polling at 3 s while a run is active (list, thread list, run history), useScheduledTask with live gating and final 404, useInView, localized error toasts; run history refreshes tasks when a run finishes - new pure modules: errors.ts (contract code to localized copy), format.ts (relative task times, viewer time, display zone), status.ts, actions.ts, run-error.ts; describeTaskSchedule in cron.ts; goal-outcome adds unchecked goal checks, describeTaskOutcome and parseStopRunId - features: scheduled_tasks block with defaults when missing - buildRunContext sends client_timezone - titleOfThread takes a localized untitled label; breadcrumb names scheduled tasks and agents; reference chips use the localized untitled label - schedule input: shared browserTimeZone, labelled selects, aria-pressed type toggles, interval minimum from the hint template - i18n: all PR1 scheduled-task keys in en-US and zh-CN, glossary fixes, recipe instructions moved into i18n - e2e mocks follow the new task, trigger, resume, thread-task and features shapes; expectNoRawIdentifiers helpers for e2e and DOM tests - tests for errors, format, cron, status, actions, goal outcome, run errors, hooks, run context, thread titles and features; scheduled e2e copy updated * feat(frontend): list-first scheduled tasks page with outcomes and editable goals - page.tsx is now a thin composition of components/workspace/scheduled-tasks: status tabs (All/Active/Paused/Finished) and search over the task list, ?task_id= deep link with router.replace on selection, ?thread_id= chip with Show all, empty state, scheduler-off notice and unavailable state - task list rows show the schedule in words and one status line (next run, running now, paused by agent, auto-paused, finished by its cap) - task detail: status badge, actions from availableActions with reasons, More actions menu (Duplicate, Copy task ID, Delete), outcome notice, Runs / Stops when / Each run's goal / Does / Notes from chat / History, origin chat link; success toasts for every action - run rows: run number or Trial run, summary, goal and assumption badges, continuations, tokens, Open chat link; raw errors and the evaluator reason only behind Details - create/edit/duplicate dialog with goal, stop condition, safety caps and advanced agent/context options; PATCH sends only changed fields, null clears a cap - renew dialog raises or removes caps and resumes in one request; a limits_exhausted Resume opens it - removed i18n keys the old page used; added feedback.resumedNoTime - recorded en-3 and zh-1 page fixtures; scheduled e2e specs rewritten for the new page; DOM tests for the detail and the form dialog - CHANGELOG entries and the frontend AGENTS.md scheduled-task note * feat(frontend): live schedule card, run conversation provenance and header entry - schedule_task results (create, update, pause, resume, trial, delete) become an assistant:scheduled-task message group rendered as a live card: schedule, next run, stop condition with the safety cap, goal, where results go, Run once now, Pause/Resume and Open task; the card polls the task only while it is on screen and shows deleted, scheduler-off and limits-exhausted states - one card per task per assistant turn; the card group is not a turn boundary for usage, branching, editing, outline or skill attribution - a human message with deerflow_scheduled_origin stays a human group with scheduledOrigin and renders as a "Scheduled run / Trial run" block with the task instructions, stop condition and notes collapsed; the launched text is never shown and the message is not editable - readable step labels for schedule_task actions and stop_scheduled_task - ThreadScheduledTasksButton replaces the header link: hidden without tasks, shows the count, links to the task (or the chat filter), and a run's chat links to its task - recorded en-3 / zh-1 chat and run-thread fixtures; chat-card and run-thread e2e specs; unit and DOM tests for parsing, grouping, turn boundaries, card, run block, header button, step labels and reconnect hydration - i18n: header.countLabelOne added, unused card.next removed; CHANGELOG and frontend AGENTS.md notes * fix(scheduler): address verification findings Move the scheduled-task lifecycle guidance from backend/AGENTS.md into the persistence guide and leave a one-line pointer, so the effective AGENTS.md chains for agents/middlewares, sandbox and subagents stay under the 98304-byte hard limit enforced by scripts/check_agent_guidance.py in lint-check. * fix(scheduler): address review findings * fix(scheduled-tasks): polish from live acceptance - zh schedule wording: an interval of one unit reads 每分钟 / 每小时 / 每秒, and a saved interval of whole days reads 每天 / 每 2 天 (Every day / Every 2 days) instead of 每 1 分钟 or 每 24 小时; several units keep the number - zh spacing: 已于{time} 满足 and 在{time} 的运行中 now leave a space between the interpolated time and the Chinese after it; a copy test guards every scheduled-task zh string against a placeholder glued to Chinese - run summary: when the first line of the final reply only leads in to a list (ends with ":" or "："), the list items follow it as plain text (bullets, numbering, checkboxes, bold, code and links stripped), joined with "；" for CJK text and "; " otherwise, within the 160-character cap - a schedule_task result (create, update, pause, resume, trial, delete) that arrives in a chat invalidates that chat's task list, the tasks list and the named task, so the header button and cards update without waiting for the idle poll; results already in the loaded history do not refetch - e2e and unit fixtures are now the live acceptance recordings (DeepSeek Flash, demo data, fictional names): live-weekday.json (create, trial, edit, pause, resume in one zh chat) and live-minute.json (per-minute chat, run 1 and run 2, paused by the agent), fetched with GET from the demo Gateway and trimmed; the hand-shaped en-3 / zh-1 fixtures are removed and the chat-card, run-thread and tasks-page specs run in both locales over the recorded data * docs(changelog): reference #6378 for the scheduled-tasks entries * docs(agents): shorten the scheduled-task pointer to stay under the guidance limit * test(scheduled-tasks): pin the live takes to their recorded time zone The live fixtures were recorded in Asia/Shanghai, and an interval task reads in the viewer's zone, so the 16:48 assertions failed on UTC CI runners. Pin the browser zone in the two live-take e2e specs and the zh live-take unit test. * fix(scheduled-tasks): keep untouched end times and drop a chat filter the new task is not in - The edit, duplicate and renew dialogs keep a stored end time's instant while its field still shows it. A minute-precision wall value cannot keep seconds or name the later 01:30 of a DST fall-back, so a title-only edit moved the cap an hour earlier, and raising the run limit re-sent the end time without its seconds. - Creating or duplicating a task from a chat's task view drops the chat filter when the new task does not belong to that chat, instead of showing "This task isn't one of this chat's tasks". * fix(scheduled-tasks): tie pause notices to the pause they describe - Paused by agent links and times only the run named in last_error. When that run is not loaded, the notice shows no link and the task's own time instead of an earlier run that also asked to stop. - The outcome notice reads the latest history page whichever page is shown, so browsing older runs no longer swaps the auto-pause reason and "Open latest run" to an earlier miss. It shares that page's request. * fix(scheduled-tasks): three lifecycle gaps found while re-checking review classes - The edit form compares a cron in the form its schedule input emits, so an untouched "0 09 * * 0,6" is not re-sent as "0 9 * * 6,0" and a title-only edit no longer re-arms or refuses a finished task. - Chat resume asks for a timezone, as update does, when a naive end_at would land in the UTC placeholder of a zone-free task. - Re-arming a task clears a host pause marker, as resume does, so a later manual pause no longer reads as "Paused by agent". * fix(scheduled-tasks): keep the notice's latest-runs query from refreshing older pages useLatestScheduledTaskRuns kept React Query's default refetch on mount, focus and reconnect, so going offline and back while an older history page was shown fetched the latest page again. Refreshing stays with the history, which refreshes the latest page only while it is shown. * test(scheduled-tasks): let the viewer's time carry its own day label Between 16:00 and 24:00 UTC, UTC and Asia/Shanghai are on different days, so the run prompt shows "Tomorrow 01:00 · Today 09:00 your time" and the fixed "01:00 · 09:00 your time" assertion failed depending on the hour. --------- Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-07 07:47:32 +08:00
Shxiao	a97772d016	fix(wechat): deny all users when allowed_users has no valid ID (#6376) ... * fix(wechat): deny all users when allowed_users has no valid ID A single iLink user ID was split into characters, and a list with no usable ID collapsed to an empty set that the inbound gate read as allow-all. * fix(wechat): fail closed on numeric and mapping allowed_users Integer-valued floats now match the sender's integer text. Fractions, non-finite numbers, and mappings no longer admit anyone, and a denied sender is dropped before inbound media is downloaded. * docs(channels): keep WeChat guidance within size budget * fix(wechat): warn on scalar allowlist separators * refactor(channels): share fail-closed allowlist parsing --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-06 21:17:11 +08:00
NanPan	a78ff4817f	fix(extensions): drain pending notify dispatches on shutdown (#6357) ... * fix(extensions): drain pending notify dispatches on shutdown * fix(gateway): await extension notify drain before reset * test(extensions): retain pending notify dispatches on shutdown * fix(extensions): bound and close notify shutdown drain * test(extensions): cover bounded notify shutdown drain	2026-10-06 20:35:54 +08:00
NanPan	ca1cae6185	fix(discord): drain thread mapping persistence across cancellation (#6356) ... * fix(discord): drain thread mapping persistence across cancellation * test(discord): retain mapping flush across cancellation	2026-10-06 15:49:27 +08:00
PeaceMaker-best	3606c4a098	feat(agents): add portable custom agent packages (#6127) ... * feat(agents): add portable agent packages Signed-off-by: PeaceMaker-best <221849497+PeaceMaker-best@users.noreply.github.com> * fix(agents): show readable package import validation errors --------- Signed-off-by: PeaceMaker-best <221849497+PeaceMaker-best@users.noreply.github.com> Co-authored-by: PeaceMaker-best <221849497+PeaceMaker-best@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-06 10:20:38 +08:00
Grapette.L	2523be658b	fix(discord): read allowed_guilds as IDs and deny every guild on an unreadable allowlist (#6338) ... * test(discord): expose allowlist parsing failures instead of opening the bot config.example.yaml documents channels.discord.allowed_guilds as a value that "can also be a single guild ID", but the constructor iterates it: a scalar string becomes one entry per character, and an unquoted YAML int raises TypeError. Whatever remains is gated by truthiness, so an allowlist with no parseable entry leaves the set empty and admits every guild. * fix(discord): read allowed_guilds as IDs, and fail closed when unreadable The allowlist was built by iterating the configured value, so the documented single-guild shorthand ("can also be a single guild ID" in config.example.yaml) became one entry per character: allowed_guilds: "321" admitted guilds 1, 2 and 3 while blocking 321, and an unquoted YAML int raised TypeError in the constructor. The empty result then read as "no allowlist", so a restriction the operator configured could open the bot to every guild the bot joined. Parse both ID lists through helpers that treat a scalar as a one-entry list and drop unreadable entries with a warning, following the telegram channel: an allowlist with no parseable entry now denies every guild and logs at ERROR. Mention exemptions keep their IDs verbatim, where an unreadable entry only leaves mention_only in force. * docs(discord): explain allowlist parsing and deny-all behavior --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-06 07:56:10 +08:00
XuRuuuy	a9c8f79dfe	fix(gateway): resolve the agent factory off the event loop (#6206) ... * fix(gateway): resolve the agent factory off the event loop start_run() called resolve_agent_factory() inline, which lazily imports the full lead-agent assembly stack (middlewares, authz, MCP, jsonschema; measured at ~8s cold on Windows, multi-second on slower filesystems). start_run is the single choke point every run-creation path flows through, so the first run after Gateway startup blocked the event loop for the whole import, stalling every other request, stream and channel on the same loop - the loop-stall family issue #5172 fixed for agent construction itself (the checkpoint-state path already resolves through the assembly pool). Resolve the factory via asyncio.to_thread: the first call pays one worker-thread hop for the import, later runs hit the cached module. Regression test pins the contract with a probe module whose module-level __getattr__ records the thread that performed the from-import. * fix(gateway): isolate factory resolution in the assembly pool Move import regressions into the strict blocking-I/O suite and cover default-executor isolation, request context, and failure-before-admission ordering. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-06 07:52:47 +08:00
haochen	8d5654363e	fix(wechat): enforce outbound limits while reading attachments (#6309) ... * fix(wechat): enforce outbound limits while reading attachments * fix(wechat): centralize outbound read overflow rejection --------- Co-authored-by: Zhangchenhao-111 <285911435+Zhangchenhao-111@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-06 07:45:18 +08:00
Hyeonsang Cho	b9ee8af328	fix(skills): keep custom-skill edit and storage lookups off the event loop (#6332) ... * fix(skills): keep custom-skill edit checks off the event loop update_custom_skill built the user-scoped storage, ran the editability probes, validated the frontmatter through a temporary directory and read the content being replaced on the Gateway loop; only the write and history append had been offloaded. Run the pre-scan checks in one worker and the replaced-content read in another, matching rollback_custom_skill, and build delete_custom_skill's storage off the loop as well. * fix(skills): build skill storage off the loop in install and skill_manage The same sweep that moved the custom-skill edit checks off the loop finds two more storage lookups on it: the archive-install helper behind both install routes, and the agent's skill_manage tool, whose lookup resolves and stats config.yaml on every call. Offload both, and pin that the caller's user context still reaches the storage lookup now that the edit route resolves it inside a worker. * docs(changelog): reference #6332 for the skill storage off-loop fix --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-06 07:20:04 +08:00
NanPan	9c5e5253ea	fix(telegram): retain polling worker on stop timeout (#6333) ... * fix(telegram): retain polling ownership on stop timeout * test(telegram): cover stop timeout ownership retry * docs(channels): pin Telegram stop ownership	2026-10-06 07:00:09 +08:00
Nan Gao	5872d07e9a	fix(gateway): gate declared multi-instance deployments and require the redis stream bridge (#6328) ... * fix(gateway): gate declared multi-instance deployments and require the redis stream bridge GATEWAY_WORKERS / WEB_CONCURRENCY only count the uvicorn workers of one process tree, so a Kubernetes Deployment with replicas > 1 (one worker per Pod) passed every multi-worker startup check while each Pod's startup orphan reconciliation wrote the other Pods' lease-less runs off as crashed on every rolling update. Add `deployment.multi_instance` as an explicit declaration that runs the same gate, plus a DEER_FLOW_MULTI_INSTANCE env override so deploy tooling can set the declaration from its replica count without editing config.yaml (wiring the Helm chart to export it is a separate change). Both the worker count and the declaration now also require a Redis stream bridge and refuse an explicit memory sandbox ownership store, since the memory bridge and ownership store are process-local. The agent-storage divergence warning, the inbound webhook dedupe warning and the WeChat QR-login guard honor the same declaration. * docs(changelog): link the multi-instance gate entry to #6328 * fix(ci): bump chart config_version to 53 and keep AGENTS.md under the size limits config.example.yaml moved to config_version 53 for the new deployment section, so the Helm chart's embedded config and its README example follow. The multi-instance notes in backend/AGENTS.md and backend/app/gateway/AGENTS.md shrink to one line each: main already sits within 55 bytes of the per-file hard limit for the gateway guide and within 163 bytes of the chain hard limit under backend/, and the full contract lives in backend/docs/CONFIGURATION.md. * fix(gateway): name every active knob in the multi-process rollback When GATEWAY_WORKERS > 1 and a multi-instance declaration are both active, the refusal offered only "Set GATEWAY_WORKERS=1", so an operator who followed it bounced through a second refusal on DEER_FLOW_MULTI_INSTANCE / deployment.multi_instance at the next start. The rollback now withdraws both knobs, and the browser-tools refusal takes the same path instead of the worker-count-only message. multi_instance_declaration() returns a frozen MultiInstanceDeclaration (source, value) with knob/rollback properties instead of a display string, so deps.py no longer branches on message prose. Tests pin the combined rollback text and that following it actually clears the gate. * docs(gateway): keep the gateway AGENTS.md under the size hard limit after merging main main grew backend/app/gateway/AGENTS.md by 30 bytes, which left it 25 bytes under the 49152-byte hard limit; the one-sentence multi-instance note from this branch pushed the merged file to 49164. Shorten that sentence by 18 bytes so scripts/check_agent_guidance.py passes on the merge result. * ci: re-run checks after test_stop_cancels_a_hung_driver_poll flaked on shard 4 tests/test_mcp_task_service.py::test_stop_cancels_a_hung_driver_poll timed out once on backend-unit-tests (4) for 2c16206ac. The MCP task service and its test are identical to main, main's run for cfe2023df passed, and 15 consecutive local runs pass; the test gives service.stop() a 1s budget while cancellation drain allows 5s, so a loaded runner can exceed it. Fork contributors cannot re-run a job, hence this empty commit. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-05 22:34:57 +08:00
Hyeonsang Cho	c2f31e440e	fix(knowledge): load the catalog's agent config off the event loop (#6313) ... * fix(knowledge): load the catalog's agent config off the event loop Both retrieval-catalog handlers called load_agent_config() directly from async code. The agent store is synchronous: file IO on the file backend, a sync SQLAlchemy round trip on the db backend, so a slow disk or database stalled every other Gateway request. Offload the load with asyncio.to_thread, matching agents.py, scheduled_tasks.py and the run-admission path in services.py. The strict Blockbuster anchors drive both handlers end to end against real file and SQLite agent stores, plus the unknown-agent 404 path. * docs(changelog): reference #6313 for the knowledge catalog fix * Added the Chinese changelog entry back --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-05 22:17:09 +08:00
Totoro	cdbcc0d9e9	feat(scheduled-tasks): show goal outcomes and end conditions in run history (#6326) ... * docs(scheduler): document tool_enabled, goal notices and goal-evaluation change Follow-up to #6229: - CONFIGURATION.md: add scheduler.tool_enabled to the example and notes. - CONFIGURATION.md, README (en/zh/pt): unmet goal runs send a goal-unmet notice instead of a completion notice, and three unmet runs add an auto-pause notice; the docs still said only success/failed notify. - CHANGELOG (en/zh): the #6229 entry now states the default-on goal evaluation change for scheduled/webhook/autonomous goal runs and that evaluator usage counts toward run usage. * feat(scheduled-tasks): show goal outcomes and end conditions in run history Follow-up to #6229. The API already returns these fields; the tasks page did not show them, so a met goal read as plain "Success", an unmet reason code rendered as a red execution error, and the goal-unmet IM notice pointed to a workspace showing neither objective nor verdict. - Task detail shows the per-run goal, max automatic runs and end time when a conversation-created task has them. - Goal runs show "Goal met" (or met relying on stated assumptions); unmet runs show a localized reason plus the host code in neutral styling. The run whose agent asked to stop the schedule is marked. - Runs without a goal, and failed runs, render as before. Read-only and frontend-only: no API change. * docs(changelog): add #6326 scheduled-task goal outcome entry * fix(scheduled-tasks): show readable unmet reasons instead of raw codes Unmet runs now show only the localized reason; the host code moves to the tooltip so it can still be matched with the IM notice. Codes without a label are still shown verbatim. * fix(scheduler): show readable goal reasons instead of internal codes Task detail now localizes the host-written last_error values from goal and stop finalization (agent stop, automatic pause, unmet reason codes) under a matching label, and Chinese copy is tightened. Goal-unmet and auto-pause IM notices state the reason in words instead of printing the raw code; unknown codes are still not forwarded. * docs(changelog): describe readable goal reasons in #6326 entry * test(scheduler): pin host goal strings with a cross-language contract Address review on #6326: - Add contracts/scheduled_goal_notes_contract.json listing the task last_error strings and unmet reason codes the tasks page and IM notices translate. A backend test checks finalization constants, blocker and stand-down codes against it; a frontend test checks every listed value has a label. - Move the two last_error strings in finalization.py into constants. - Frontend reason lookup strips the blocked: prefix like the IM map and now covers goal_not_met_yet, with en/zh labels. --------- Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com> Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-05 21:56:04 +08:00
Hyeonsang Cho	0223d949bf	fix(threads): remove a deleted thread's files off the event loop (#6319) ... * fix(threads): remove a deleted thread's files off the event loop DELETE /api/threads/{id} called shutil.rmtree over the thread directory directly on the event loop, so deleting a thread with a large workspace stalled every other Gateway request and live SSE stream until the whole tree was gone. Branch copying in the same router already offloads its filesystem work through run_file_io; deletion did not. The removal now runs on the file-IO pool. It is wrapped in await_drained rather than bare-awaited: cancelling the await abandons the worker, not the removal, so the durable delete reservation would otherwise release while files are still being deleted, and a newly admitted run could write into a directory that is about to disappear. * docs(changelog): reference #6319 in the thread delete off-loop entry --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-05 21:27:46 +08:00
JasonH	22623d1b00	fix(projects): validate explicit document names before staging (#6287)	2026-10-05 18:38:22 +08:00
Shxiao	b85e4ae74b	fix(channels): serialize lifecycle mutations under per-channel lock (#6304) ... * fix(channels): serialize lifecycle mutations under per-channel lock * fix(channels): invalidate stale config snapshots across lifecycle mutations under per-channel lock	2026-10-05 14:35:51 +08:00
Jun	57d946b730	fix(browser): drain live cleanup before releasing session (#6284) ... * fix(browser): drain live cleanup before releasing session * test(browser): cover cancellation precedence during cleanup * style(browser): separate cancellation regressions	2026-10-05 12:15:21 +08:00
Hyeonsang Cho	c540399a5e	fix(gateway): scope per-run reads to the run's data identity (#6282) ... * fix(gateway): scope per-run message and event reads to the run's data identity start_run stamps run-event rows with the raw trusted owner id, but GET /runs/{rid}/messages and /runs/{rid}/events called the event store with user_id=AUTO, which resolves to the internal caller's make_safe_user_id form. On the database event store, owners whose id contains characters outside [A-Za-z0-9_-] (IM channel ids such as "feishu:owner-777") therefore got an empty list. The regenerate source-run scan had the same mismatch and fell back or returned 409. Pass _run_scope_user_id() explicitly, as the thread message routes already do (#5448), and add user_id to RunEventStore.list_messages_by_run() so every backend accepts it like list_messages()/list_events(). Browser and API sessions keep their per-user filter. * fix(gateway): scope workspace-changes and archive reads to the run's data identity The same raw-owner mismatch reached two more run-scoped routes. On the SQL stores, GET /runs/{rid}/workspace-changes reported no changes because its event lookup used user_id=AUTO, and GET /runs/{rid}/artifacts/archive answered 404 because both its run-row lookup and its run.delivery event lookup did. Pass _run_scope_user_id() to both, and let get_workspace_changes_response() forward an explicit user_id to the event store. * docs(changelog): reference #6282 in the run-scope read fix entries --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-10-05 10:23:55 +08:00