fix(wiki): purge through the plugin page actions and count reset deletions #101
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ShadowsOverWestgate/sow-tools#101
Reference in New Issue
Block a user
Closes #99. Closes #100.
#99 — purge used the core topic API
deploy-wiki --stale-policy purgedeleted pages withDELETE /api/v3/topics/{tid}. On a NodeBB runningnodebb-plugin-westgate-wikithat is refused for topics in wiki categories — revision history is plugin-owned — so every purge failed with HTTP 400 and the deploy exited 1.Purge now goes through the plugin's own page actions:
PUT /api/v3/plugins/westgate-wiki/page/tombstoneDELETE /api/v3/plugins/westgate-wiki/page/hard-purgein that order, because a page must be tombstoned before it can be purged. A page that is already gone answers 404 on the tombstone and is treated as a completed purge, as before.
Archive was audited and needs no change. It rewrites the page through
updatePost, which is an ordinary post edit the plugin allows; only delete, restore, and purge are reserved to the page actions.The wiki home topic. A namespace reset enumerates every topic in the category, including the home page, which the plugin excludes from tombstone, restore, and purge alike. Those are now skipped instead of aborting the reset. NodeBB answers 403 for that and for a token without purge privileges alike, and the response body cannot tell the two apart — what can is scope. A category where nothing at all could be deleted is a privilege problem, so the run still fails there rather than writing a manifest that claims a fresh start over pages that are all still present.
The fakes. Every fake NodeBB in
wiki_deploy_test.gonow goes through one constructor that refuses native topic mutation exactly the way the plugin does. The old fakes answered the core API, which is how a purge path that has never worked in production stayed green in CI.#100 —
stale: 0abovepurged: 1213The reset purge never went through stale computation, so the preview reported zero deletions on a run that would delete every topic in the managed categories.
Reset deletions are now counted in
stale, which is the number callers word their destructive-policy warning around, and the summary gains a line naming the reset and how many of its targets the manifest has no record of writing:The unrecognized subset is the number worth surfacing, since those are the deletions a re-seed cannot undo. The
--reset-managed-namespaceshelp text now says plainly that the flag deletes every page in the managed categories, not only the ones this deployer wrote.DeployResultis exported so the console reads named fields instead of eleven positional ints.Verification
go vet ./...andgo test ./...pass. New tests cover the plugin purge order, the already-missing page, the skipped undeletable topic, the per-category privilege failure, and the reset counts.deploy-wiki purged pages with DELETE /api/v3/topics/{tid}. A NodeBB running nodebb-plugin-westgate-wiki refuses that for topics in wiki categories, because wiki revision history is plugin-owned, so every purge failed with HTTP 400 and the deploy exited 1. Purge now goes through the plugin's own page actions: tombstone the page, then hard-purge it, since a page must be tombstoned before it can be purged. Archiving is unaffected: it rewrites the page through the ordinary post edit the plugin allows, rather than deleting anything. Every fake NodeBB in the deploy tests now goes through one constructor that refuses native topic mutation the way the plugin does. The old fakes answered the core API, which is why this shipped green. A namespace reset can reach pages NodeBB will not delete at all - the wiki home topic above all - so those are skipped rather than aborting the reset. NodeBB answers 403 for that and for a token without purge privileges alike, and the response cannot tell them apart; what can is scope, so a category where nothing at all could be deleted still fails the run. Under --reset-managed-namespaces the preview reported stale: 0 on a run that would delete every topic in the managed categories, because the reset purge never went through stale computation. The reset deletions are now counted as stale, which is the number callers word their destructive-policy warning around, and the summary names how many of them the manifest has no record of writing - the deletions a re-seed cannot undo. Closes #99 Closes #100 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>Corrects the bullet added in the previous commit. It read "tea api can read but not write", which described the symptom rather than the rule. `tea api` sends only the login's `token:` field and never signs requests with the SSH key, so on an SSH-only login every authenticated call fails with `{"message":"token is required"}` — writes and authenticated reads alike. Anonymous reads against these public repos still succeed, which is why it looked like a read/write split. Adding a token to the login makes the raw endpoints work in both directions, confirmed by a POST to the issue labels endpoint that applied and read back. The `tea issues` / `tea pr` subcommands authenticate over SSH and keep working with no token at all. That asymmetry is the confusing part, so it is now stated outright. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>New commits pushed, approval review dismissed automatically according to repository settings