deploy-wiki purge uses the core NodeBB topic API, which the wiki plugin rejects #99

New Issue

2026-08-05T15:19:16Z

archvillainette commented

2026-08-05 15:19:16 +00:00

crucible wiki deploy-wiki --stale-policy purge cannot delete any page on a NodeBB running nodebb-plugin-westgate-wiki. It calls the core topic API, which the plugin blocks by design, so every purge fails with HTTP 400 and the deploy exits 1.

Reproduction

sow-topdata deploy-wiki run on 2026-08-05, stale_policy=purge, reset_managed_namespaces=true, dry_run=false. The dry-run preview planned 1213 purges, then the live phase died on the first one:

deploy wiki page "classes:reset-topic-2366": purge NodeBB topic 2366:
NodeBB DELETE /api/v3/topics/2366 failed: HTTP 400:
{"status":{"code":"bad-request","message":"Use the wiki page actions to delete, restore, or purge wiki pages."}}
Error: Process completed with exit code 1.

Cause

purgeTopic in internal/topdata/wiki_deploy.go:1614-1618 issues DELETE /api/v3/topics/{tid}.

nodebb-plugin-westgate-wiki refuses native mutations on topics in wiki categories — lib/pages/wiki-native-mutation-guards.js:22-24 raises exactly the message above. That guard is deliberate and ADR-backed (sow-nodebb ADR-0006, "wiki revision history is plugin-owned"), so the plugin is not the side that should change.

The plugin's own routes are registered in library.js:200-225:

Action	Method	Route
Tombstone a page	PUT	`/api/v3/plugins/westgate-wiki/page/tombstone`
Restore a page	PUT	`/api/v3/plugins/westgate-wiki/page/restore`
Hard-purge one page	DELETE	`/api/v3/plugins/westgate-wiki/page/hard-purge`
Purge tombstoned in bulk	DELETE	`/api/v3/plugins/westgate-wiki/pages/purge-tombstoned`

Note the ordering constraint: lib/controllers/wiki-manage.js:67-69 reports "Tombstone this page before it can be purged", so hard-purge is not a one-shot replacement for the core delete — a page must be tombstoned first. The wiki home topic is excluded from tombstone, restore, and purge alike and will need special-casing.

archive policy deserves the same audit; it is presumably routed through the same native calls.

Why the tests did not catch it

Every deploy test stands up a fake NodeBB that answers the core API — internal/topdata/wiki_deploy_test.go:2022 asserts DELETE /api/v3/topics/7 and returns success. The fake accepts what the real plugin rejects, so the purge path is green in CI and broken in production. Whatever the fix is, the fake needs to reject native topic mutation the way the plugin does, otherwise the next regression lands the same way.

Impact

--stale-policy purge has never worked against this NodeBB. It fails closed and loudly, so no data was lost, but any run that reaches a non-empty purge set exits 1 and the deploy does not complete. Blocks ShadowsOverWestgate/sow-topdata#198.

`crucible wiki deploy-wiki --stale-policy purge` cannot delete any page on a NodeBB running `nodebb-plugin-westgate-wiki`. It calls the core topic API, which the plugin blocks by design, so every purge fails with HTTP 400 and the deploy exits 1. ## Reproduction sow-topdata `deploy-wiki` run on 2026-08-05, `stale_policy=purge`, `reset_managed_namespaces=true`, `dry_run=false`. The dry-run preview planned 1213 purges, then the live phase died on the first one: ``` deploy wiki page "classes:reset-topic-2366": purge NodeBB topic 2366: NodeBB DELETE /api/v3/topics/2366 failed: HTTP 400: {"status":{"code":"bad-request","message":"Use the wiki page actions to delete, restore, or purge wiki pages."}} Error: Process completed with exit code 1. ``` ## Cause `purgeTopic` in `internal/topdata/wiki_deploy.go:1614-1618` issues `DELETE /api/v3/topics/{tid}`. `nodebb-plugin-westgate-wiki` refuses native mutations on topics in wiki categories — `lib/pages/wiki-native-mutation-guards.js:22-24` raises exactly the message above. That guard is deliberate and ADR-backed (sow-nodebb ADR-0006, "wiki revision history is plugin-owned"), so the plugin is not the side that should change. The plugin's own routes are registered in `library.js:200-225`: | Action | Method | Route | | --- | --- | --- | | Tombstone a page | PUT | `/api/v3/plugins/westgate-wiki/page/tombstone` | | Restore a page | PUT | `/api/v3/plugins/westgate-wiki/page/restore` | | Hard-purge one page | DELETE | `/api/v3/plugins/westgate-wiki/page/hard-purge` | | Purge tombstoned in bulk | DELETE | `/api/v3/plugins/westgate-wiki/pages/purge-tombstoned` | Note the ordering constraint: `lib/controllers/wiki-manage.js:67-69` reports "Tombstone this page before it can be purged", so hard-purge is not a one-shot replacement for the core delete — a page must be tombstoned first. The wiki home topic is excluded from tombstone, restore, and purge alike and will need special-casing. `archive` policy deserves the same audit; it is presumably routed through the same native calls. ## Why the tests did not catch it Every deploy test stands up a fake NodeBB that answers the core API — `internal/topdata/wiki_deploy_test.go:2022` asserts `DELETE /api/v3/topics/7` and returns success. The fake accepts what the real plugin rejects, so the purge path is green in CI and broken in production. Whatever the fix is, the fake needs to reject native topic mutation the way the plugin does, otherwise the next regression lands the same way. ## Impact `--stale-policy purge` has never worked against this NodeBB. It fails closed and loudly, so no data was lost, but any run that reaches a non-empty purge set exits 1 and the deploy does not complete. Blocks ShadowsOverWestgate/sow-topdata#198.

archvillainette added the Kind/Bug label 2026-08-05 15:37:38 +00:00

archvillainette referenced this issue from a commit

2026-08-05 15:44:26 +00:00

fix(wiki): purge through the plugin page actions and count reset deletions

archvillainette referenced a pull request that will close this issue

2026-08-05 15:44:46 +00:00

fix(wiki): purge through the plugin page actions and count reset deletions #101

archvillainette closed this issue

2026-08-05 16:01:52 +00:00

archvillainette referenced this issue from a commit

2026-08-05 16:01:53 +00:00

fix(wiki): purge through the plugin page actions and count reset deletions (#101)