chore(release): v4.1.0 — Data Durability & Recovery #482
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/release-v4.1.0"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes out the v4.1.0 milestone — 22 issues, 0 open.
APP_VERSIONandBOT_EXPECTED_APP_VERSIONboth4.0.1→4.1.0.make check-versionspasses.BOT_CONTRACT_VERSIONstays at 1 — verified, not assumedThree commits touched
/api/bot/*since v4.0.1, so I read the diff rather than trusting the shape of the changes:guild_idandnotification_channel_idto a bot response. Optional on both sides by design — the bot declares themstr | None = Nonewith a comment saying explicitly that an older backend omitting them must still parse, in which case recovery declines rather than guessing.deleted_at IS NULLfilters to the guild lookup and the/asklore context. Response shapes unchanged; both narrow which rows come back, to outcomes an older bot already handles — the guild lookup's 404 is a documented case it denies on.So a self-hoster can upgrade the backend and bot images independently. The changelog preamble says so, since that is exactly what people read it for.
Migrations
Two, both additive — nullable columns and partial indexes, no data rewritten:
e3f4a5b6c7d9f4a5b6c7d8eaBoth verified up → down → up against a real Postgres.
f4a5b6c7d8eais head.Release-notes extraction checked
release.ymlextracts the version's section fromCHANGELOG.md, and an empty release body is the documented failure mode. I ran the workflow's own regex against this file: 24,765 characters extracted for4.1.0, correct boundaries, no bleed into the4.0.1section.That also required fixing a pre-existing missing blank line before the
## [4.0.1]header. It would probably have extracted anyway, but I would rather not have this release's notes depend on "probably".What is in it
The milestone's own framing — nothing a GM has made can be destroyed by a single click, a crashed worker, or a background job they never saw run. Headline items: campaign and wiki soft delete with a 30-day trash and a 7-day floor, off-host backups, audio reaching deletion only through a trash, per-speaker recording that streams to disk, crash recovery for interrupted recordings, and the retention sweep no longer eroding anything restorable.
Two operator-visible changes are called out in the changelog preamble: deleted things now occupy disk for 30 days, and there is a new optional
RESTART_POLICYin.env.After this merges
Tag
v4.1.0onmainand push, which firesrelease.yml. Deploy to dev and validate before prod — not deploying anything as part of this PR.🤖 Generated with Claude Code
chore(release): v4.1.0 — Data Durability & Recoveryto chore(release): v4.1.0 — Data Durability & Recovery