Log upload to support fails with HTTP 413 if logs are bigger than 10MB backend limit

[ethicnology]

Description

Users attempting to send their logs to the support team receive an HTTP 413 (Payload Too Large) error because their local log file exceeds the backend ingestion limit (10 MB, confirmed with the backend team). The background log prune task does not enforce this cap, so log files are allowed to grow beyond what the backend accepts. The user is blocked from reporting issues at the exact moment they need support.

Reproduce

1. Use the app over an extended period until the local log file exceeds 10 MB.
2. Go to the support section and trigger "Send logs to support".
3. Observe the upload fails with HTTP 413 (Payload Too Large).

Expected behavior

The background log prune task should enforce a hard upper bound on the local log file size so that any log submission to the support endpoint is guaranteed to succeed with respect to size. Pruning should also run opportunistically right before a "send logs" action, so a stale schedule cannot block a user. When trimming, the oldest entries should be dropped first to preserve the most recent (and most relevant) logs.

Context

• BULL: candidate/release X.X.X
• OS: Android 16.X.X / iOS 18.X.X
• Device: Google Pixel 10 / Iphone 16e
• Extra: GrapheneOS with/without Google Services

Platforms

• Android
• iOS

Demo

N/A — reproducible by inspecting log file size before triggering upload.

---

Notes for the implementer

• Backend hard limit: 10 MB. Suggested client cap: 9 MB to leave headroom for HTTP envelope, auth headers, and multipart boundaries.
• If logs are compressed before upload, apply the cap to the compressed size (that's what the backend measures).
• Add a test asserting that after pruning, the resulting file is ≤ the configured cap.
• Consider logging locally when a prune actually trims content, so future support reports can indicate whether a user hit the cap.

[ethicnology]

limited at 100kb