7 Commits

Author	SHA1	Message	Date
Hyeonsang Cho	5bda01f524	fix(gateway): answer malformed run bodies with 4xx instead of 500 (#7362) ... * fix(gateway): answer malformed run bodies with 4xx instead of 500 RunCreateRequest types config, context and input as free-form dicts, so some bodies it accepts still failed during run admission with an exception nothing mapped, and the run routes answered 500: - a non-object config.configurable (build_run_config's dict.update, and .get in the stateless thread selector) - a non-object config.context (build_run_config's own ValueError) - an assistant_id that does not normalize to letters, digits and hyphens - a non-string agent_name in config.configurable, config.context or context (_load_scope_agent_config) - an AI message whose tool_calls is a string, object or list of strings (AttributeError from LangChain's validator) The request model now requires config.configurable and config.context to be objects or null (422 invalid_run_config_section), and build_run_config checks configurable as it already checked context. start_run maps build_run_config's ValueError to 422, as it does for validate_thread_id. Message conversion also maps AttributeError to its existing 400, and a non-string agent_name gets the existing 422 for an unresolvable agent. All of these fail before admission, so no run is created. * docs(changelog): reference #7362 for the malformed run body fix * docs(changelog): note the configurable shapes #7362 now rejects	2026-10-24 10:12:05 +08:00
Totoro	92e9afe6ea	feat(context): support client context capabilities (#7051) ... * feat: support client context capabilities (cherry picked from commit b7c223f9415dcd545cbe05a5f5a6e47073a42d68) [Totoro-qaq: resolved onto main. The persisted-reminder middleware hunks and their tests are dropped (delivery is redesigned in a follow-up); the RunCreateRequest description moved to app/gateway/run_models.py.] * fix: address client context review comments (cherry picked from commit bce6da6b819228eda58e887872720b6f9b5fab69) [Totoro-qaq: middleware hunks dropped with the redesigned delivery.] * feat(agents): deliver client context as a request-scoped data block The cherry-picked #3106 put context.client into the persisted first-turn reminder, with change detection and a "not provided" clear marker. Main has since moved the date reminder to a SystemMessage, made request-scoped context (the project block, #5443) request-only, and agents/AGENTS.md now requires user-influenced values to ride the HumanMessage data channel, never system text. Render runtime.context["client"] on every model call in DynamicContextMiddleware.wrap_model_call/awrap_model_call as one hidden HumanMessage right after the leading SystemMessages, where DurableContext puts its data. It is never a state update and never flagged dynamic_context_reminder, so nothing is checkpointed, summarized or replayed, and a run without a client gets no block. An unchanged client keeps the previous request as the next request's prefix. The renderer sanitizes again (direct graph callers bypass the Gateway), html-escapes values and frames them with frame_untrusted_text: the same --- BEGIN/END USER INPUT --- boundary the user's own turn and the MCP task notification get. The lead prompt treats everything outside those markers as framework data, so unframed values would rank above the user's own text; framed, context.client can say nothing the same caller could not already say in input.messages. client_context joins _BLOCKED_TAG_NAMES so a forged block in user input or a tool result is escaped, and one static, value-free sentence in the lead prompt names the block as untrusted hints, never instructions, permissions or identity. The now unused empty-context marker is removed. * fix(gateway): log dropped context.client fields without values A run request is never rejected over context.client: unknown fields, nested values and malformed entries are silently dropped, the same leniency as the other context keys. That left no signal when a custom client sent something the Gateway ignored (review on #3106). Route both the config.context.client and the body context.client paths through one helper that emits a debug line whenever sanitizing changed the value. Like the malformed client_timezone branch, the line carries no values; unlike client_timezone, client.name and preference strings are free caller-controlled text, so they are never logged, not even sanitized. A clean client, an explicit null or an absent key logs nothing. Tests also pin the config-only path (sanitized before the early return) and the end-to-end start_run admission: the sanitized client reaches config["context"] and never configurable. * fix(runtime): bound numeric client context preferences String preferences are capped at 200 characters, but integers were kept at any size. A JSON body may carry integers of up to 4300 digits, so 32 of them rendered a block of about 138,000 characters, re-sent on every model call of the run. In-process callers could also pass an int past the str() digit limit, which failed the model call, or a number subclass with its own __str__. Keep integers within JavaScript's Number.MAX_SAFE_INTEGER, the range a browser client can send exactly, and coerce numbers to plain int and float. * docs(api): describe client context as advisory request-scoped hints The cherry-picked section described a hidden reminder that no longer exists. Document what a custom client can rely on: the allow-list and its limits (strings, the integer range, and only the first 32 entries of each map), debug-level logging of dropped fields, runtime-only forwarding, and delivery as a per-request user-role block, framed like user input, rather than system text or thread history. Only top-level context.client is documented. An explicit config.context.client is sanitized for the run as well, but the run record keeps the caller's config as sent, so it is not offered as an alternative. It also answers the #3106 review: capabilities and preferences are advisory hints, not enforcement, which belongs outside the model; name is informational and never for authorization; the same object should be sent on every run to keep the cached prefix stable; subagents and embedded DeerFlowClient runs do not receive it, and server-started runs (schedules, IM channels, GitHub agents, MCP notifications, extensions unless the plugin passes one) carry none. * fix(context): declare client delivery and keep client out of configurable The request-only <client_context> block is model-visible, so DynamicContextMiddleware now declares its delivery and the sanitizer's limits in release_policy_parameters(); runs before and after this change no longer share a policy fingerprint. build_run_config copies body.config['configurable'] verbatim and configurable is persisted with checkpoints, so a client placed there is dropped instead of being stored raw. Client context stays runtime-only. Document context.client in the README and in the middleware guide. * fix(context): apply the PII redaction policy to the client block DynamicContextMiddleware adds the <client_context> message inside the outer PiiRedactionMiddleware, and the hidden message is not re-sanitized, so with pii_redaction enabled a preference such as an email address reached the model verbatim while the same address in the user turn was redacted. Pass the rendered block through the shared redact_text seam with this middleware's app_config.pii_redaction, and declare the setting in release_policy_parameters(). * fix(context): keep client hints out of stored run config --------- Co-authored-by: Blair Leng <25675774+BlairLeng@users.noreply.github.com> Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com>	2026-10-19 10:41:18 +08:00
Totoro	5b591a9039	feat(gateway): accept conversation references in run context and report the capability (#5463) ... * feat(gateway): accept conversation references in run context and report the capability LangGraph SDK clients build a fixed run body and drop unknown top-level fields, so they cannot send the conversation_references field from #5399. RunCreateRequest now lifts context.conversation_references into the top-level field before validation, so it keeps the same bounds and error locations, and drops it from context, so it never reaches the merged run context or the checkpointed configurable. Sending both is a 422. GET /api/features reports conversation_references {enabled, max_references} with the same "tool is configured" predicate as run admission, so a client can hide an entry point on deployments without the tool. Related to #5398. * fix(gateway): report the field type error for a malformed top-level reference list A malformed top-level conversation_references sent alongside a context list now fails with the field's own type error instead of the conflict message. The tool-configured predicate reads tool.use directly, and the features test doubles carry that attribute like every real ToolConfig. * fix(gateway): treat every list-like top-level reference value as a conflict Pydantic's lax mode coerces tuples, sets, frozensets and deques into the list[str] field, so a direct Python caller passing one of those together with context.conversation_references now reports the conflict instead of slipping both grants through. Unreachable over HTTP, where JSON has no such types. * fix(gateway): ask pydantic whether a top-level reference value is list-like Enumerating list-like types cannot track pydantic's lax acceptance set (generators, UserList, dict key views also coerce into list[str]). The conflict guard now validates the top-level value with a TypeAdapter for list[Any]: whatever pydantic would coerce reports the conflict when it is non-empty, and whatever it rejects still surfaces the field's own type error. Regression tests cover deque, UserList, dict keys and a generator, plus rejected scalars. * fix(gateway): probe top-level references with the field's own annotation The conflict guard now validates the top-level value with the exact item annotation the field uses, so its acceptance set is the field's rather than a superset: an item the field rejects (an empty string, a non-string, the ints of a range or dict view) surfaces the field's own item error instead of a conflict. The annotation is shared through one alias so the two cannot drift. * fix(gateway): materialise a one-shot iterator before probing top-level references The item-validating probe could consume a generator while collecting an item error, after which the field re-validated the exhausted iterator, coerced it to [] and let the request through with the key still in context. Iterators are now read once into a list that both the probe and the field validate, so a bad item is reported at its index and a valid generator is kept. * fix(gateway): materialise every once-walkable iterable before probing references Pydantic coerces any iterable into the list field, and an object whose __iter__ hands out a generator once is not an Iterator instance, so the previous gate let it reach the probe and be consumed. The lift now reads every iterable except lists, tuples and the shapes the field rejects as a whole (str, bytes, dict) into a list first, so the probe and the field always validate the same items. --------- Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com>	2026-09-16 15:37:57 +08:00
Totoro	533e30e7f2	[feat] add opt-in conversation reads for Gateway runs (#5399) ... * feat: add scoped conversation reads to gateway runs * refactor: share conversation tool path and reuse parsed text --------- Co-authored-by: Totoro-qaq <279883115+Totoro-qaq@users.noreply.github.com>	2026-09-14 10:51:01 +08:00
Vanzeren	095092418c	fix(gateway):unify thread id validation (#4589) ... * fix(gateway): unify thread ID validation at the API boundary Thread ID entry points accepted arbitrary strings while downstream consumers (filesystem paths, Kubernetes Provisioner, JSONL event store) each enforced different character restrictions, so invalid IDs were persisted first and only failed later during sandbox/workspace init. Centralize validation in deerflow.utils.thread_id (pattern ^[A-Za-z0-9_-]{1,64}$): validate at routers, RunCreateRequest, scheduler dispatch, paths.py, JSONL store, embedded client, and align the Provisioner pattern (pinned by a parity test). UUIDs are still generated only when no ID is supplied; caller-supplied opaque IDs stay supported. Deliberate exceptions: DELETE /threads/{id} keeps str as the legacy cleanup escape hatch (filesystem cleanup guarded), read-only client.get_thread stays unvalidated, and scheduler rows with legacy invalid IDs record a failed dispatch instead of raising out of the poll loop. * docs: document canonical thread ID contract README: caller-supplied thread IDs need not be UUIDs; the canonical pattern and per-endpoint behavior. AGENTS.md: the shared deerflow.utils.thread_id contract, its enforcement boundaries, and the legacy-ID escape hatches. * fix(gateway): close thread ID validation gaps at remaining entry points Follow-up to the canonical thread ID contract: a full audit found the uniform-422 coverage only reached about half of the thread_id surfaces. - routers: 18 routes still took a bare thread_id: str — 13 in thread_runs.py (including the five messages/events/workspace-changes reads that returned 500 on the JSONL event store vs 404/empty on the DB store), 4 read routes in threads.py, and the suggestions route flagged in review. DELETE /api/threads/{id} keeps str as the declared legacy-cleanup escape hatch. - client: upload_files/delete_upload/list_uploads/get_artifact now validate up front, fulfilling the RFC's 'all mutating entry points' clause (get_thread stays unvalidated as the declared legacy read path). - tui: the /resume literal-ref fallback validates against the canonical contract and reports a descriptive error instead of failing deep in the client. - scripts/support_bundle.py: replace the drifted dot-allowing pattern with a byte-identical copy of THREAD_ID_PATTERN (kept local so the script still runs with a broken venv). * test(gateway): guard the canonical thread ID contract against regressions - test_thread_id_route_contract.py: static AST sweep asserting every route handler with a thread_id parameter annotates ThreadId (whitelist: the DELETE escape hatch), plus a runtime sweep hitting all 44 thread_id routes with a non-canonical ID and asserting a 422 that names thread_id, plus a websocket upgrade-rejection case. - test_thread_id_validation.py: client entry-point validation, support_bundle pattern parity, and TUI literal-ref fallback tests. - Align two tests that encoded the old contract (dotted IDs).	2026-08-01 19:42:44 +08:00
Aari	e646188ab4	fix(runtime): accept the SDK's default stream_resumable=false (#4468) ... RunCreateRequest declared stream_resumable as None-only, but langgraph_sdk defaults it to False (not None) and its payload filter only drops None, so every SDK request carried "stream_resumable": false and was rejected with 422. False means "no resumable stream", which is what DeerFlow already serves. This broke every IM channel run (runs.stream and runs.create both send the field; only runs.wait omits it) and any external langgraph_sdk client. The web frontend was unaffected because its compatibility wrapper does not send it. An explicit true still returns 422. The new regression test drives a real SDK client to capture its default payload and posts that to the HTTP boundary, so a future non-None SDK default cannot regress this silently. Fixes #4466	2026-07-26 15:00:42 +08:00
ShitK	a4ede80deb	fix(runtime): reject unsupported run options and stream modes (#4430) ... * fix(runtime): reject unsupported run options * fix(runtime): align SDK run compatibility * fix(frontend): avoid unsupported events stream mode --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>	2026-07-24 19:24:24 +08:00