Full-resolution screenshots in bug reports

Status: Delivered
CAS: CAS-2545
Delivered: 2026-05-13
PRs: #664

What’s new

You can now include full-resolution screenshots when submitting a bug report through the iOS app. Previously the CloudBridge daemon imposed an undocumented 2 MB request cap — screenshots hit this limit and forced the reporter to either drop the image or post a cropped version. The cap is now 10 MB, which accommodates a full-screen iOS screenshot at native resolution.

How to use it

No change to the workflow. In the bug-report chat, tap Attach Screenshot as before. Screenshots up to approximately 6 MB are now accepted without any size warning. If a screenshot somehow exceeds the new cap, the app shows an explicit “file too large (10 MB max)” message instead of a silent failure.

What changed under the hood

Axum router: DefaultBodyLimit::max(10 * 1024 * 1024) added to the CloudBridge daemon router — this was the actual enforcement point (handler-level guards were unreachable before).
Daemon constants: MAX_REPORT_PAYLOAD_B64_BYTES = 10_000_000, MAX_REPORT_SCREENSHOT_BYTES = 6_000_000 (headroom for base64 encoding overhead on the screenshot).
iOS user copy: payload_too_large error string updated to mention the 10 MB cap explicitly.
Cargo.toml: removed a duplicate tauri-plugin-dialog entry introduced during earlier dependency alignment.

Why we built it

The regent discovered the cap while testing iOS bug-report submission — the only way to get a report through was to omit the screenshot entirely. Since screenshots are the most useful diagnostic artifact in a bug report (they capture the exact UI state at failure), silently capping them below usable sizes defeats the purpose of the feature. The fix was a one-line router change that had been missed because the app-level constants gave the false impression the limit was already in place.

Known limitations / follow-on work

The daemon currently stores report payloads in memory before processing; very large batches of concurrent reports could create memory pressure. For now this is acceptable given beta-scale usage.
The frontend does not yet pre-compress screenshots before sending; a future optimization could reduce payload size at the call site rather than relying on the server cap.