fix(mcp): bound tool response size so large logs return instead of hanging

[SomethingNew71]

Fixes #88.

The bug

Every MCP tool result travels as a single Server-Sent Event, and streamable-HTTP MCP clients cap one SSE event at 1 MiB (DEFAULT_MAX_EVENT_SIZE_BYTES in the reference client). An event over the cap is discarded inside the client's SSE decoder — the caller receives no value and no error.

evaluate_formula and get_channel_data serialized one entry per log record, so past roughly 22,000 rows the payload crossed the cap and the call simply never returned. The reporter was right to rule out both of their leads: the IPC layer's 30s timeout never fired because nothing had actually timed out, and the expression engine was never the bottleneck.

Reproduction

Driving the real MCP server with the reference Python MCP client against a stub IPC responder:

rows	payload	reference MCP client	raw HTTP body
27,000	1,020,285 B	OK, 0.14s	delivered, 0.13s
28,000	1,059,305 B	hang, >60s	delivered, 0.12s

The raw HTTP body arrives correctly in the failing case, so the loss is entirely on SSE decode. The cliff sits exactly where the payload crosses 1,048,576 bytes. (The stub's values are shorter per row than real telemetry, which is why this cliff is at 28K and the reporter's at 23K — same byte boundary.)

The fix

Two defenses:

1. Sample budget — limit_samples reduces any per-record series to DEFAULT_MAX_POINTS (2000), clamped to MAX_POINTS_LIMIT (10,000), reusing the chart's LTTB so peaks and dropouts survive rather than being strided past. Both commands take an optional max_points; responses report total_samples and downsampled. find_peaks is capped at MAX_PEAKS (500) — its output scales with channel noise rather than with anything the caller asked for, so it had the same latent bug — and reports total_peaks/truncated so a truncated list is never mistaken for a complete one.
2. Byte guard — json_result serializes compactly (the previous to_string_pretty put one array element per line, roughly doubling the payload for nothing) and refuses anything over MAX_RESPONSE_BYTES (512 KiB) with an error naming max_points and the time range. Every tool handler routes through it, so a future per-record tool is covered by default.

Statistics stay exact. channel_series is a new accessor for the full un-downsampled series; get_channel_stats, find_peaks and correlate_channels read through it, and evaluate_formula holds the same invariant by calling compute_stats before limit_samples. Nothing computes aggregates over 2000 samples when the log has 178,000.

Ragged logs no longer panic the GUI. Log::get_channel_data is a filter_map that drops a row missing the column, so a ragged log yields a times/values pair that is misaligned, not merely short — and downsample_lttb indexes values off times.len(). require_aligned rejects that pair up front, matching how src/ui/chart.rs already refuses to plot it.

New wire fields are #[serde(default)], so payloads written before the budget existed still parse.

Verification

End to end through the reference MCP client:

evaluate_formula rows=178000 max_points=None  -> 0.045s returned=2000  total=178000 downsampled=True stats.count=178000 bytes=69999
evaluate_formula rows=178000 max_points=10000 -> 0.070s returned=10000 total=178000 downsampled=True stats.count=178000 bytes=349291
find_peaks                                    -> 0.014s peak_count=500 total_peaks=41337 truncated=True bytes=26889

500,000 rows also returns in 64 ms with a 70 KB payload. max_points: 999999 clamps to 10,000.

Full suite green (1098 tests, 16 new), cargo fmt --all -- --check and cargo clippy --all-targets -- -D warnings clean.

Release

Version bumped to 2.14.1 across Cargo.toml, Cargo.lock, README.md, docs/index.html and docs/sitemap.xml. 2.14.0 was already released, so without the bump the release workflow (which greps the version out of Cargo.toml) would re-tag it and the in-app updater would never offer this fix to existing installs.

https://claude.ai/code/session_01CDnphU9sfMQiPBxHqXvqYo

---

Generated by Claude Code