Erase recordings: "regenerate summaries" never regenerates anything #797

New issue

Closed

opened 2026-09-24 02:49:15 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-09-24 02:49:15 +00:00

Collaborator

Found by the #791 delegate. I confirmed it against main (a028f55).

Members → erase this person's recordings offers to regenerate the affected sessions' summaries. It sends regenerate_summaries: true (Members.jsx:892, and also CampaignDetail.jsx:1164). run_member_erasure then calls:

process_audio.delay(str(session.id), str(audio_dir), guild_id, channel_id, 0)

It doesn't pass replace_existing=True. process_audio's overwrite guard (reminder_tasks.py ~2843, from #397/#425) refuses any session whose transcript_updated_at is set, unless the caller passes replace_existing. Every session an erase scrubs has a transcript by definition, so the guard refuses every one. It logs "refusing to overwrite it" and returns. The checkbox does nothing, and the GM is never told.

The guard is deliberate. The comment at the guard names this exact door: a regeneration here used to overwrite a different GM's edited summary. So the fix isn't simply adding replace_existing=True. The options:

A. Regenerate, keeping a GM's edits. Pass replace_existing=True only for sessions whose summary has not been edited by hand. Leave an edited summary alone and tell the GM which sessions those were. This needs a way to tell "edited by hand" apart. Check what #397 used.
B. Remove the option. The erase already removes the member's lines from the transcript. The summary may still mention them, and the dialog could say so, with a per-session "regenerate" link on the session page that already carries the right warnings.
C. Always overwrite. This re-opens #397. Not recommended.

Recommendation: B. It is honest about what happens, and the per-session reprocess already exists with its own overwrite confirmation. A is a larger change to a privacy flow for a rare case.

Owner decision needed. This belongs to lane 3 (Members, #729).

🤖 Generated with Claude Code

Found by the #791 delegate. I confirmed it against main (a028f55). **Members → erase this person's recordings** offers to regenerate the affected sessions' summaries. It sends `regenerate_summaries: true` (`Members.jsx:892`, and also `CampaignDetail.jsx:1164`). `run_member_erasure` then calls: ```python process_audio.delay(str(session.id), str(audio_dir), guild_id, channel_id, 0) ``` It doesn't pass `replace_existing=True`. `process_audio`'s overwrite guard (`reminder_tasks.py` ~2843, from #397/#425) refuses any session whose `transcript_updated_at` is set, unless the caller passes `replace_existing`. **Every session an erase scrubs has a transcript by definition**, so the guard refuses every one. It logs "refusing to overwrite it" and returns. The checkbox does nothing, and the GM is never told. The guard is deliberate. The comment at the guard names this exact door: a regeneration here used to overwrite a *different* GM's edited summary. So the fix isn't simply adding `replace_existing=True`. The options: - **A. Regenerate, keeping a GM's edits.** Pass `replace_existing=True` only for sessions whose summary has not been edited by hand. Leave an edited summary alone and tell the GM which sessions those were. This needs a way to tell "edited by hand" apart. Check what #397 used. - **B. Remove the option.** The erase already removes the member's lines from the transcript. The summary may still mention them, and the dialog could say so, with a per-session "regenerate" link on the session page that already carries the right warnings. - **C. Always overwrite.** This re-opens #397. Not recommended. **Recommendation: B.** It is honest about what happens, and the per-session reprocess already exists with its own overwrite confirmation. A is a larger change to a privacy flow for a rare case. Owner decision needed. This belongs to lane 3 (Members, #729). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot referenced this issue

2026-09-24 03:08:45 +00:00

Retention counts from a session's first processing, not its last edit (#791) #800

claude-bot referenced this issue

2026-09-24 03:37:28 +00:00

Erasing one member's recordings restarts everyone else's retention clock #791

claude-bot referenced this issue

2026-09-24 04:07:41 +00:00

Build lane 3: the campaign core and Settings (CAMP-1 to CAMP-17, SH-7) #729

claude-bot commented

2026-09-24 04:29:59 +00:00

Author

Collaborator

Owner, 2026-09-24: option B. "If somebody leaves we can do best-effort to remove them, but nothing that breaks the story that was told." This is recorded as D94.

What will change:

The erase dialog loses its "regenerate summaries" option, on Members and on the older campaign page if it's still reachable.
The dialog says plainly what happens. Their recordings and their lines in each transcript are removed, best-effort. Recaps and summaries stay as written.
The dead regenerate_summaries path is removed from the request schema, the router and run_member_erasure. This isn't the bot API, so there's no contract bump.

🤖 Generated with Claude Code

**Owner, 2026-09-24: option B.** "If somebody leaves we can do best-effort to remove them, but nothing that breaks the story that was told." This is recorded as **D94**. What will change: - The erase dialog loses its "regenerate summaries" option, on Members and on the older campaign page if it's still reachable. - The dialog says plainly what happens. Their recordings and their lines in each transcript are removed, best-effort. Recaps and summaries stay as written. - The dead `regenerate_summaries` path is removed from the request schema, the router and `run_member_erasure`. This isn't the bot API, so there's no contract bump. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot referenced this issue

2026-09-24 04:51:49 +00:00

Build lane 4: sessions (SESS-1 to SESS-7) #730