ai-dynamo/dynamo

Describe the Bug Dynamo's Responses API converter silently drops non-empty backend reasoning_content when the request does not include reasoning.summary. The same model output is available as reasoning_content through /v1/chat/completions, so the reasoning parser and backend transport have already done their work. The loss happens while Dynamo converts Chat Completions output into Responses API output. This affects both streaming and non-streaming Responses requests: Streaming requests emit no reasoning item and no response.reasoning_text.* events. Non-streaming requests omit the reasoning output item. A later request that replays a raw reasoning item only reads its summary, not its content. If reasoning.summary is requested, Dynamo currently maps the backend's raw reasoning_content into summary events. That path should keep working, but it should not be the only way to preserve reasoning. Steps to Reproduce Run Dynamo with a reasoning parser and a model that emits reasoning, using

Description Gemma 4 31B consistently segfaults using the current Dynamo main vLLM runtime. vLLM version: 0.27.1 Reproduction Run inside the Dynamo container, replacing MODEL_PATH with the Gemma snapshot path: VLLM_USE_V2_MODEL_RUNNER=1 python3 -m dynamo.vllm \ --model "$MODEL_PATH" \ --served-model-name google/gemma-4-31B-it \ --discovery-backend file \ --trust-remote-code \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --max-num-batched-tokens 8192 \ --max-num-seqs 128 \ --gpu-memory-utilization 0.9 \ --enable-prefix-caching \ --enable-chunked-prefill \ --reasoning-parser gemma4 \ --dyn-tool-call-parser gemma4 \ --dyn-reasoning-parser gemma4 \ --custom-jinja-template /workspace/examples/chat_templates/gemma4_tool.jinja \ --model-loader-extra-config '{"enable_multithread_load":true,"num_threads":128}' \ --no-enable-log-requests \ --enforce-eager \ --kernel-config '{"enable_flashinfer_autotune":false,"enable_cutedsl_warmup":false,"enable_jit_war

Summary Audit examples/ and make every supported, user-facing example or template discoverable from the documentation website, primarily through the corresponding section of the Recipes tab. Parent tracker: #13278 The Recipes tab currently exposes model recipes, backend CLI templates, DGD/DGDR templates, and feature benchmarks. The repository contains additional backend, deployment, feature, custom-backend, router, planner, diffusion, and cloud examples that are only discoverable by browsing GitHub or following incidental links from individual pages. The Reference > Examples page currently points readers to a small subset and ends with a link to browse the entire directory. It does not provide enough information to choose between the available examples. Current gaps The audit should cover every directory and user-facing Markdown file under examples/, not only directories that already have a README.md. Examples that currently appear to have no direct website representation include: Tri

Summary Create a first-class Observability documentation tab and establish it as the canonical home for metrics, traces, logging, health checks, dashboards, and observability setup across local and Kubernetes deployments. Observability content is currently spread across the Local/CLI Guide, Kubernetes Guide, Developer Guide, backend sections, and Reference, with overlapping subsets and inconsistent ownership. Consolidating the shared material will make the content easier to discover and reduce drift. Parent tracker: #13278 Suggested owner: @Jont828 Scope Add Observability as a top-level Fern navigation tab rather than nesting its primary guide under Kubernetes Operations. Inventory the current local, Kubernetes, Developer Guide, backend-specific, and Reference observability pages. Define one canonical owner for each topic: installation, deployment-specific setup, metrics and dashboards, traces, logging, health checks, architecture, backend-specific behavior, and reference material. Co

Follow-up from #12966 (merged as 73729d9), raised by @rmccorm4 in review: In future, we should further raise an explicit error type representing overloaded from backend python workers instead of propagating an http code error/json Problem #12966 made the frontend classify overload from the error chain rather than the worker-supplied payload code, so ErrorType::ResourceExhausted / WorkerOverloaded now maps to the configured overload status (529 by default) instead of leaking the worker's 503. That fix only engages when the backend actually emits a typed rejection. The most common Python-worker shape does not: map_python_exception (lib/bindings/python/rust/engine.rs) and py_err_to_dynamo (backend.rs) only map exceptions carrying a .code in 400..500 into a typed category. A worker rejecting on its own admission limit uses 503, which is outside that range, so the result is ErrorType::Backend(BackendError::Unknown) with the JSON envelope {"message":"Worker local total request limit reach