* fix(document): allow render-pdf to be framed and 503 cleanly on missing PyMuPDF
Fixes#2101.
Two related bugs in the PDF-form library preview flow:
1. SecurityHeadersMiddleware was sending X-Frame-Options: DENY and
frame-ancestors 'none' on /api/document/{doc_id}/render-pdf, but
static/js/documentLibrary.js embeds the response in an <iframe> for
the library card preview. The browser blocked the load with
ERR_BLOCKED_BY_RESPONSE, leaving the user with a blank panel.
Extend the existing is_tool_render exemption to also cover
/api/document/.../render-pdf. Per-document owner checks still run in
the route handler, so the exemption is scoped the same way as the
tool-render exemption it mirrors. /api/document/.../export-pdf is
left untouched — it's a download (Content-Disposition: attachment),
not an iframe embed.
2. routes/document_routes.py:render_pdf called fill_fields, which
raises RuntimeError via _require_fitz() when the optional PyMuPDF
dependency isn't installed. That RuntimeError bubbled out as a
generic 500 with a cryptic 'PDF render failed' detail.
Reuse the existing _load_pdf_viewer_fitz() helper to fail fast with
a 503 and a user-actionable install hint (mentions
requirements-optional.txt and AGPL-3.0), matching the convention
used by the other PDF endpoints.
Tests cover both fixes:
- middleware headers on /api/document/.../render-pdf (iframeable, but
X-Content-Type-Options and Referrer-Policy are still set)
- middleware headers on /api/document/.../export-pdf (must stay strict)
- middleware path matching precision (similar-but-different paths stay
strict)
- middleware headers on /api/tools/.../render (no regression)
- middleware headers on /api/chat (no regression)
- render-pdf returns 503 with install hint when PyMuPDF is missing
- 503 is raised before any file I/O (fail-fast ordering)
* chore: address maintainer feedback on PDF previews same-origin framing and comment trimming
* chore: make render-pdf regression tests order-independent
Thinking models served via llama.cpp without --reasoning-format none
(e.g. Qwen3, DeepSeek-R1) route all tokens into reasoning_content and
return content="". Two call paths were silently broken:
- llm_call / llm_call_async (non-streaming): hard-keyed
data["choices"][0]["message"]["content"] raises KeyError or returns
empty string, discarding the entire response.
- stream_agent_loop end-of-round fallback: when full_response is empty
but round_reasoning has content, the existing code replaced the
response with the generic empty-response error message, discarding
all reasoning tokens that were correctly accumulated during streaming.
Fix: in both non-streaming paths use msg.get("content") or
msg.get("reasoning_content") or "". In the streaming fallback, surface
round_reasoning as the answer before falling through to the error path.
* fix(mcp): invalidate tool prompt cache on connect/disconnect/error
get_tool_descriptions_for_prompt cached its result keyed only on
(disabled_map, len(_tools)). If a server reconnects with the same
tool count (or transitions to error state), the cache was never
busted — the agent received stale tool descriptions for the new
connection state.
Add a _generation counter incremented on every structural change
(successful connect, disconnect, connection error) and include it in
the cache key.
* test(mcp): regression test for _generation cache invalidation
Shreyas S Joshi