feat: workspace owners can permanently delete a channel

[sercada]

Maintainer edits

MUST: Keep Allow edits from maintainers enabled for this PR so maintainers
can help update the branch when needed.

What Problem This Solves

Workspace owners can archive a channel but cannot remove a channel they no longer
want, together with its messages and files.

User Impact

User impact: owners can delete a channel from Channel settings → Delete
channel..., from the API, or with clickclack channels delete. The dialog
shows what will be removed (messages, thread replies, pins, topics, files and
their size), offers to archive instead, and enables deletion only after the
channel name is typed. Deletion is permanent. People viewing the channel are
moved to their fallback conversation with a notice. The server refuses to
delete a workspace's last channel and the Guests workspace's provisioned
channels. On SQLite, two new migrations make deleting many messages fast: a
10k-message channel in a 120k-message workspace now deletes in 0.3 s instead of
6.6 minutes. Existing workspace deletion benefits the same way.

Why This Change Was Made

• Deletion reuses the existing foreign-key cascade in one transaction, so the
  channel, messages, replies, reactions, pins, channel topics, read pointers,
  and notification settings go together. Uploads attached only to that channel
  are removed and their objects go through the durable cleanup queue already
  used for workspace deletion; uploads still used elsewhere and the workspace
  icon are kept. The audit log records the channel and the removed counts.
• On SQLite, every row removed by the cascade did two full scans: one of
  messages to find replies and quotes (parent_message_id and
  quoted_message_id had no index), and one of the FTS5 search index, because
  the delete trigger matched the unindexed messages_fts.message_id. Deleting
  a channel therefore grew with channel size × workspace size. New partial
  indexes cover the child keys on both stores, and message_search_rows records
  each message's FTS rowid so the search triggers update rows by rowid. Both
  are needed; either alone leaves most of the cost.
• A workspace-scoped channel.deleted event tells clients to leave the channel.
  Earlier events for the channel stay in the log, so replay cursors remain valid;
  realtime delivery already skips events whose channel no longer exists.
• On PostgreSQL, a deletion locks the workspace row (FOR NO KEY UPDATE) before
  it counts or selects anything, in the same workspace-first order as workspace
  deletion and updates. Competing deletions cannot both pass the last-channel
  check, and the workspace icon cannot move onto an upload being removed; event
  appends and inserts, which take KEY SHARE, are not blocked. Candidate uploads
  are then locked FOR UPDATE and re-checked, so an attachment elsewhere either
  commits first (and the upload is kept) or waits and fails its foreign key.
• Only human owners can delete. Moderators, members, and bot tokens get 403;
  blocked deletions return 409 with a blocker code the web app explains.
• clickclack channels delete deletes only a channel named with --channel on
  its own command line (global or subcommand form). CLICKCLACK_CHANNEL and the
  saved default channel pick the channel for everyday commands, so they never
  choose what gets deleted. Without --yes the command prints the counts and
  exits.

The new migrations (sqlite/0043, sqlite/0044, postgres/0036) share numbers
with the agent question migrations in #258. Migrations apply by file name, so both
work together; whichever PR lands second can renumber to keep the sequence tidy.

Evidence

Settings danger zone	Confirmation with preview	Another member when it is deleted

The CLI with a default channel in the environment, real server and CLI from
the same build:

Previous head `aa459dd5`: channels delete --yes deleted #launch from CLICKCLACK_CHANNEL

# previous-head-aa459dd5: workspace with #launch and #old-launch (2 messages); the shell exports CLICKCLACK_CHANNEL=launch
channels: launch old-launch
$ clickclack channels delete --yes
  deleted #launch: 0 messages, 0 thread replies, 0 files
  exit=0
channels: old-launch
$ clickclack channels delete --channel old-launch
  cannot delete #old-launch: 2 messages, 0 thread replies, 0 files (last_channel)
  exit=1
$ clickclack channels delete --channel old-launch --yes
  cannot delete #old-launch: 2 messages, 0 thread replies, 0 files (last_channel)
  exit=1
channels: old-launch

This head: the default channel is ignored; the named channel is deleted after the preview

# branch: workspace with #launch and #old-launch (2 messages); the shell exports CLICKCLACK_CHANNEL=launch
channels: launch old-launch
$ clickclack channels delete --yes
  usage: clickclack channels delete --channel CHANNEL --yes
  exit=1
channels: launch old-launch
$ clickclack channels delete --channel old-launch
  refusing to permanently delete #old-launch: 2 messages, 0 thread replies, 0 files without --yes
  exit=1
$ clickclack channels delete --channel old-launch --yes
  deleted #old-launch: 2 messages, 0 thread replies, 0 files
  exit=0
channels: launch

Tests:

• Shared store suite on SQLite and Postgres (channeldeletiontest): the
  channel's messages, topics, search results, and exclusive upload are removed
  while other channels, shared uploads, and the workspace icon survive; the
  deletion counts match the preview; a replay cursor pointing at one of the
  channel's old events still replays forward to channel.deleted; guard rails
  for the last channel, provisioned Guests channels, archived channels, and
  non-owners.
• TestCascadeChildKeysUseIndexes (SQLite query plan) and
  TestCascadeChildKeyIndexesExist (Postgres).
• PostgreSQL interleavings, held open with real locks instead of timing:
  TestDeleteChannelSerializesLastChannelDecisions runs two deletions of a
  workspace's last two channels (one succeeds, one gets last_channel), and
  TestDeleteChannelKeepsUploadsAttachedDuringDeletion attaches the channel's
  only upload elsewhere while the deletion is paused after choosing it (the
  attachment either keeps the upload or fails). Both pass three times in a row;
  against the previous revision they fail with deleted=2 blocked=0 remaining=0
  and attachment succeeded but kept 0 rows.
• TestSearchTriggersFindRowsThroughTheRecordedRowid: upgrades a database with
  an existing message, detaches the search rows from their message IDs, then
  edits one message and deletes the other's channel; both rows are still
  replaced or removed and search returns the edited message. With the old
  message_id triggers it fails with detached rows = 2.
• TestChannelDeletionHTTP: 403 for members and bot tokens, 404 for
  unknown or already deleted channels, 204 for the owner, the live and
  replayed channel.deleted event on a member's socket, the audit entry, and
  the last_channel blocker with 409.
• TestChannelsDeleteRequiresExplicitConfirmation: the CLI prints the preview
  and refuses without --yes.
• TestChannelsDeleteIgnoresDefaultChannels runs the CLI entry point with
  CLICKCLACK_CHANNEL, then with a saved default channel: channels delete --yes
  sends no DELETE, while --channel in either flag position deletes. Without the
  fix it fails with CLICKCLACK_CHANNEL chose the channel to delete.
• tests/e2e/channel-deletion.spec.ts: an owner deletes after reviewing the
  preview and typing the name; a member watching the channel is moved out with
  a notice; the last channel cannot be deleted.
• apps/web/src/lib/channel-deletion.test.ts: name confirmation, blocker
  messages, and the notice text.
• Local CI steps: pnpm fmt:check, pnpm lint, pnpm typecheck,
  pnpm -r typecheck, web unit tests, pnpm docs:site, and go test ./...
  with CLICKCLACK_POSTGRES_TEST_DSN, deadcode, and the embedded build is
  current and repeatable (coverage gate 86.8%). On this machine these tests also
  fail on unchanged main: TestHTTPBodyDeadlineStillBoundsStalledRequestBodies,
  uploadstore TestR2HeaderNetworkLifecycle/progressing_PUT, and intermittently
  TestHTTPErrorPathsAndSPA (1 of 4 runs on main), and
  TestHTTPSlashCommandRequiresChannelWriteAuthorityBeforeCallback (1 of 5 runs
  on main, 5 of 5 pass on this branch). The first CI run's Playwright job
  failed once in chat.spec.ts › clicking the active conversation does not refetch its messages; locally that test passes 3 of 3 alone and the whole
  chat.spec.ts plus channel-deletion.spec.ts pass 42 of 42 with two workers.

Deleting a channel on SQLite (Python sqlite3 3.45 applying the real
migrations; 120,000 messages in 12 channels; the deleted channel has 7,000
roots, 2,500 thread replies, and 500 quote replies):

Schema	Delete time
main	395.4 s
child-key indexes only	220.3 s
this PR (indexes and search row map)	0.29 s

Applying this PR's migrations to that populated database took 0.14 s. A
smaller run (30,000 messages, 3,000 deleted) shows the two fixes are
independent: 27.7 s on main, 11.5 s with only the search row map, 17.7 s with
only the indexes, and 0.10 s with both.

AI-assisted: prepared with Claude Code; I reviewed the change and the evidence.

🤖 Generated with Claude Code

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge.

What this changes

This PR lets human workspace owners permanently delete a channel and its exclusive content through the browser, API, SDK, and CLI.

Example: An owner removes #old-launch containing two messages while keeping #launch.

• Before: Archiving #old-launch hides it while retaining its history.
• After: Explicitly confirmed deletion removes #old-launch and its two messages.

Review scores

Measure	Result	What it means
Overall readiness	🦪 silver shellfish (2/6)	Strong shipped-behavior evidence supports the main flow, but three client defects block merge and product direction and shipped upgrade compatibility remain unresolved.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): Inspected browser screenshots show deletion settings, preview, confirmation gating, and member fallback; the real-server CLI transcript exercises explicit selection, refusal without confirmation, and successful deletion, while HTTP/store coverage exercises forbidden callers before destructive effects.
Patch quality	🦪 silver shellfish (2/6)	3 actionable review findings remain.

Product

Kind: Feature · Worth it: Needs a maintainer decision · Fix scope: Complete
User problem: Owners can archive unwanted channels but cannot permanently remove their history and exclusive files.
Reason: Permanent deletion offers clear value but adds an irreversible retention capability, public lifecycle contract, and persisted table without an owner decision.

Merge readiness

⛔ Blocked before merge - 6 items remain

This PR adds a useful capability absent from current main, but three client-state defects block merge and permanent deletion still needs an owner decision.

Priority: P2
Reviewed head: c6d1ef841098ed1874b460bde5e5ba62fe0568d1
Owner decision: Required. See Decision needed.

Decision needed

• Question: Should ClickClack expose permanent human-owner channel deletion with this API, SDK contract, and persisted search-table migration?
• Recommendation: Approve the scoped capability: Accept owner-only permanent deletion with preview, explicit confirmation, and archive as the reversible alternative, subject to the repairs and compatibility proof.
• Why: The capability has clear value, but existing archive and permission decisions do not approve irreversible deletion, and no maintainer approval was found on this PR.

Before merge

• Retire pending channel-list reads before removing the channel (P2) - An owner can delete while a channel-list refresh has captured the old list but its response is delayed. DELETE completion reaches this filter independently of the realtime queue without advancing channelsLoadSerial, so loadChannels accepts that old response and restores the deleted sidebar entry. Invalidate or reconcile pending list reads before applying deletion. This retains the previously acknowledged late finding on the unchanged reviewed head.
• Prevent pending searches from restoring deleted channel content (P2) - A member can search a channel, navigate to another conversation while retaining the search pane, and receive channel.deleted while an initial or next-page response is delayed. This filter removes loaded rows but leaves searchRequestID unchanged, allowing the response to replace or append deleted messages and broken channel links. Retire those requests or reconcile their results against deletion before admission; this repeats the existing finding on the unchanged head.
• Handle channel deletion in embedded conversation views (P2) - When an owner deletes a channel open in /embed/channel, this handler receives channel.deleted but ignores it, leaving removed history and the composer active. Embedded threads likewise delegate to a thread owner that does not recognize this channel-scoped deletion. Handle the event in both views, retire pending reads, and clear the conversation into its unavailable state. This is a late discovery: the same omission was visible at the earlier reviewed head, and comparison confirms these consumers are unchanged.
• Complete next step - Resolve GitHub-reported merge conflicts against main while preserving owner-only channel settings established by fix: moderators get channel settings that fail with a database error #256.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.
• Add data-model compatibility proof - The review found that existing stored data may not work after upgrade. Show that existing data still loads and works with this change.

Findings

• [P2] Retire pending channel-list reads before removing the channel — apps/web/src/ChatApp.svelte:594-598
• [P2] Prevent pending searches from restoring deleted channel content — apps/web/src/ChatApp.svelte:600-604
• [P2] Handle channel deletion in embedded conversation views — apps/web/src/components/embed/EmbedChannelView.svelte:372-373

Tests

• Low-value test apps/web/src/lib/channel-deletion.test.ts: Remove wording-only blocker and notice assertions that pin helper text already exercised by browser coverage; retain meaningful confirmation checks.
• Missing end-to-end proof: Provide a shipped-server upgrade from v0.7.0 showing existing settings, messages, uploads, and search remain intact; supplied migration evidence is a store test and populated-schema benchmark.

Agent review details

How this fits together

Channel lifecycle requests pass through HTTP authentication and transactional owner checks, then produce database cascades, durable events, and queued upload cleanup.

flowchart TD
  A[Browser CLI and SDK] --> B[Channel HTTP handlers]
  B --> C[Transactional authorization]
  C --> D[SQLite and PostgreSQL]
  D --> E[Durable deletion event]
  D --> F[Upload cleanup queue]
  E --> G[Browser conversation state]

Loading

Technical review

Best possible solution:

If approved, retain transactional deletion and durable cleanup while making every browser consumer reject state belonging to a deleted channel.

Do we have a high-confidence way to reproduce the issue?

The response races and ignored embedded deletion event follow directly from source; no target code or tests were executed during this read-only review.

Is this the best way to solve the issue?

Transactional deletion and existing cleanup ownership provide a sound foundation, but deletion must also govern pending-response admission and embedded conversation state.

Full review comments:

• [P2] Retire pending channel-list reads before removing the channel — apps/web/src/ChatApp.svelte:594-598
  An owner can delete while a channel-list refresh has captured the old list but its response is delayed. DELETE completion reaches this filter independently of the realtime queue without advancing channelsLoadSerial, so loadChannels accepts that old response and restores the deleted sidebar entry. Invalidate or reconcile pending list reads before applying deletion. This retains the previously acknowledged late finding on the unchanged reviewed head.
  Confidence: 0.98
  Late finding: first raised on code an earlier review cycle already covered.
• [P2] Prevent pending searches from restoring deleted channel content — apps/web/src/ChatApp.svelte:600-604
  A member can search a channel, navigate to another conversation while retaining the search pane, and receive channel.deleted while an initial or next-page response is delayed. This filter removes loaded rows but leaves searchRequestID unchanged, allowing the response to replace or append deleted messages and broken channel links. Retire those requests or reconcile their results against deletion before admission; this repeats the existing finding on the unchanged head.
  Confidence: 0.98
• [P2] Handle channel deletion in embedded conversation views — apps/web/src/components/embed/EmbedChannelView.svelte:372-373
  When an owner deletes a channel open in /embed/channel, this handler receives channel.deleted but ignores it, leaving removed history and the composer active. Embedded threads likewise delegate to a thread owner that does not recognize this channel-scoped deletion. Handle the event in both views, retire pending reads, and clear the conversation into its unavailable state. This is a late discovery: the same omission was visible at the earlier reviewed head, and comparison confirms these consumers are unchanged.
  Confidence: 0.97
  Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.97

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against e9938a42620d.

Provenance checked

• SQLite FTS trigger replacement changes intended behavior with a stated reason (cff5fb0: The prior migration scopes search within FTS; improve: show matched context in search results #81 preserves authorized, bounded search results, and this PR explains and benchmarks replacing unindexed deletion scans with rowid lookup.)
• Channel settings and archival keeps the original intent (fix: add channel archive controls for managers #153: Expose reversible archive and restore controls while retaining history; this PR keeps archive available as an alternative.)
• Browser request ownership keeps the original intent (bfc8fc6: Guard stale asynchronous recovery responses and serialize event projection; deletion retains the existing generations but does not extend admission rules to the new lifecycle event.)
• Composer notice scope changes intended behavior with a stated reason (ad89e31: Scope delayed command callbacks and notices to their conversation; the new carried notice intentionally survives deletion-driven fallback navigation while preserving slash-dispatch invalidation.)
• Embedded JavaScript output keeps the original intent (fix(build): preserve generated JavaScript literal whitespace #255: Preserve compiler-emitted literal whitespace; regenerated assets do not restore the removed whitespace normalizer.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Capability remains absent from main: Current main registers channel PATCH and message endpoints but neither channel DELETE nor deletion preview; scoped source and GitHub searches found no merged replacement. (apps/api/internal/httpapi/server.go:245, e9938a42620d)
• Pending channel-list admission: Deletion filters channels without advancing channelsLoadSerial; loadChannels subsequently accepts a delayed pre-deletion response when its captured serial still matches. (apps/web/src/ChatApp.svelte:596, c6d1ef841098)
• Pending search admission: Deletion filters loaded results without retiring searchRequestID; initial and pagination responses can restore deleted-channel results. (apps/web/src/ChatApp.svelte:600, c6d1ef841098)
• Embedded consumers omit deletion: EmbedChannelView handles channel.updated but ignores channel.deleted; EmbedThreadView delegates to a thread owner that recognizes message and thread events, leaving deleted conversation state active. (apps/web/src/components/embed/EmbedChannelView.svelte:372, c6d1ef841098)
• Supplied shipped behavior: Inspected screenshots show #asia-sales settings, a four-message and 13 KB file preview, disabled incomplete-name confirmation, and a member moved to #general; the PR supplies real-server CLI output demonstrating explicit channel selection and deletion. (c6d1ef841098)
• Persistent search migration: The migration creates and backfills message_search_rows and replaces FTS triggers; the focused upgrade test and populated-schema benchmark support it but do not show a shipped-server upgrade from v0.7.0. (apps/api/internal/store/sqlite/migrations/0044_message_search_rows.sql:5, c6d1ef841098)

Likely related people:

• Shakker: Raw commit cff5fb0 adds apps/api/internal/store/sqlite/migrations/0033_search_workspace_fts.sql:26 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: cff5fb042e85; files: apps/api/internal/store/sqlite/migrations/0033_search_workspace_fts.sql)

Labels

Label changes:

No label changes.

Label justifications:

• P2: This optional lifecycle feature has bounded client-state defects and does not establish an urgent released regression.
• merge-risk: 🚨 compatibility: The PR adds a public API/SDK contract and a persisted search table whose shipped upgrade compatibility remains unproven.
• merge-risk: 🚨 session-state: Delayed responses and embedded consumers can retain or restore state belonging to permanently deleted channels.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦞 diamond lobster and patch quality is 🦪 silver shellfish.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.
• proof: sufficient: Contributor real behavior proof is sufficient.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only; repair and merge need explicit maintainer commands such as @clawsweeper autofix or @clawsweeper automerge.

History

Review history (22 earlier review cycles; latest 8 shown)

• reviewed 2026-10-09T03:40:18.885Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-09T09:55:23.003Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-09T13:37:05.310Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-09T15:31:26.158Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-09T23:03:16.239Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-10T11:02:25.846Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-10T12:58:14.998Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content
• reviewed 2026-10-10T14:49:03.459Z sha c6d1ef8 :: blocked before merge. :: [P2] Retire pending channel-list reads before removing the channel | [P2] Prevent pending searches from restoring deleted channel content

Reviewed October 10, 2026, 1:46 PM ET / 17:46 UTC (Revision 23).