A mass-backup webhook that exceeded ~2 KB used to be silently
truncated by `desc = message[:MAX_EMBED_DESC]` with MAX_EMBED_DESC
set to 2048 — half of Discord's real description limit and far
below what a multi-VM backup digest produces. The trailing jobs
just vanished from the channel.
Bring the channel up to Discord's actual webhook contract:
* description limit raised to the real 4096-char cap
* if the body still doesn't fit, split it on line boundaries into
one embed per chunk so every backup entry is preserved
* keep title + fields on the first embed only; attach the footer
and timestamp to the last embed so the rendered card has the
normal head/tail framing even when split across many embeds
* enforce Discord's 6000-char-per-embed cap (title + description +
every field name+value) — only kicks in when many large fields
combine with a chunk already near the description ceiling
* batch up to 10 embeds per webhook POST (Discord's per-message
limit) and POST additional messages sequentially with a 0.4 s
gap so a >10-embed digest doesn't trip the 5/2 s webhook rate
limit
Verified with synthetic mass-backup payloads:
* 14 KB / 200 jobs → 4 embeds, 1 POST
* 60 KB / 60 lines → 15 embeds, 2 POSTs (10 + 5)
New AppImage SHA-256:
16ad59ea63a64e5be460cd73f87315e8b39b756bf1c61f3cb2019e9fa3e76361
Closes#220.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
New build picks up the get_disks_observation_counts NVMe-rename fix.
SHA-256:
3b44eb1172b4b1b7e6a36d1c9f1cd5a237ec04d52543bb791358525b0653a402
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The tracked binary still pointed at the build made before the
last two fixes landed (resolution_reason persistence in
health_persistence and disk-temp breakdown alignment in
storage-overview). Re-build the AppImage so the GitHub-published
binary matches what is actually running on the deploy targets.
New SHA-256:
d043e2f27f21315931ab53d87f02390b1a66b0c1730e8b7699aafb565809efbb
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
