Skip to main content

Module request

Module request 

Source
Expand description

Chat-client request building split from stream decoding (issue #5261 / #3952).

The TUI’s crates/tui/src/client.rs + client/chat.rs (~9.7k + 6.3k lines) mix three concerns: (1) building the MessageRequest (provider shaping, cache inspection, tool-result compaction, reasoning replay), (2) decoding the SSE stream, and (3) prompt inspection. This module owns concern (1) in crates/core so TUI and headless exec build byte-identical requests for identical inputs. The decoder and inspector stay in the TUI’s client/ until their own moves; this file already guarantees parity because both callers go through the same builder.

The builder is deliberately small and provider-neutral. It does NOT rewrite the turn loop, guards, or compaction logic — it moves them.

Structs§

ChatMessage
ChatRequest
Provider-neutral chat request that both TUI and headless produce. Every consumer — TUI run_event_loop, CLI exec, app-server, tests — builds this one type so headless == TUI is a byte-equality property.

Functions§

build_chat_request
Build a ChatRequest from already-assembled prompt + history. The function is pure and deterministic: same inputs → same JSON bytes. Both the TUI engine (handle_deepseek_turn / refresh_system_prompt) and the headless exec call this, so the parity invariant is structural, not best-effort.
byte_parity
Verify that two requests are byte-identical (the invariant the suite checks for every headless vs TUI pair). Returns None on equality, Some(diff) on the first differing byte index for diagnostics.
preview_human
Preview / dryrun rendering: the human-readable table form of the request that Op::PreviewOutboundRequest returns without sending. This mirrors crates/tui/src/core/engine/preview.rs but lives in core so the same preview is returned headlessly.
render_request_bytes
Deterministic JSON byte rendering for parity checks (headless == TUI). The bytes are what is actually put on the wire; /dryrun (#1004) and the test harness compare these directly rather than re-serializing with different key order.