reset-managed-namespaces reports stale: 0 while queuing every topic in the category for deletion #100

New Issue

2026-08-05T15:19:22Z

archvillainette commented

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

Under --reset-managed-namespaces, the deploy preview reports stale: 0 while the same run has queued every topic in the managed categories for deletion. The preview is the readout an operator uses to decide whether a destructive run is safe, and in this mode it does not describe what the run will do.

What it looks like

sow-topdata deploy-wiki, stale_policy=purge, reset_managed_namespaces=true, dry run:

local pages: 1200
created:     1200
updated:        0
skipped:        0
stale:          0
archived:       0
purged:      1213
drifted:        0

stale: 0 sits directly above purged: 1213. sow-topdata's wrapper prints, immediately before this block, "stale-policy=purge: of the pages counted as 'stale' below, they will be DELETED from NodeBB" (scripts/deploy-wiki.sh:148-158). Read together, the operator is told zero pages will be deleted on a run that would delete 1213.

Cause

planNodeBBDeploy (internal/topdata/wiki_deploy.go:498-506) adds the reset plans straight to result.Purged and then discards the manifest:

resetPlans, purged, err := planManagedNamespaceReset(opts, client, progress)
...
result.Purged += purged
manifest = wikiDeployManifest{Version: "nodebb-v1", Pages: map[string]wikiDeployManifestPage{}}

Nothing touches result.Stale, because the reset purge never goes through stale computation at all. It is a second, independent deletion path.

The documented model says otherwise

sow-topdata's wrapper documents the contract it was given, at scripts/deploy-wiki.sh:32-36 and :92-94: "the deployer deletes only pages the manifest says we wrote", and "crucible computes the stale set from the deploy manifest only: no manifest => nothing is stale => archive/purge delete nothing". Under --reset-managed-namespaces neither statement holds. That repo built a fail-closed gate (require_page_history, deploy-wiki.sh:99-117) on top of the assumption, and its recovery advice at :102 tells operators to re-seed with RESET=1 — the exact flag that bypasses the model the gate protects.

Scope of the reset enumeration

Worth stating plainly in the docs, because it is easy to assume otherwise: planManagedNamespaceReset (internal/topdata/wiki_deploy.go:685-730) calls client.listNamespacePages(cid) and queues every topic it returns. There is no filter on the managed-region marker that wiki/wiki.yaml configures (page_marker_prefix: sow-topdata-wiki). So the reset purges the whole category, including topics crucible never wrote. In the run above that is the 13-topic gap between 1213 purged and 1200 recreated.

That may well be the intent of a re-seed. The problem is that no output distinguishes "1200 pages I own" from "13 pages I have never seen", and the count that would have flagged it reads 0.

Suggested fix

Report the reset purges in a field that the preview's destructive-policy warning actually covers — either fold them into stale, or print a distinct line naming them as a namespace reset and how many of them are unrecognized. The unrecognized subset is the number worth surfacing, since those are the deletions a re-seed cannot undo.

Found while working ShadowsOverWestgate/sow-topdata#198.

Under `--reset-managed-namespaces`, the deploy preview reports `stale: 0` while the same run has queued every topic in the managed categories for deletion. The preview is the readout an operator uses to decide whether a destructive run is safe, and in this mode it does not describe what the run will do. ## What it looks like sow-topdata `deploy-wiki`, `stale_policy=purge`, `reset_managed_namespaces=true`, dry run: ``` local pages: 1200 created: 1200 updated: 0 skipped: 0 stale: 0 archived: 0 purged: 1213 drifted: 0 ``` `stale: 0` sits directly above `purged: 1213`. sow-topdata's wrapper prints, immediately before this block, "stale-policy=purge: of the pages counted as 'stale' below, they will be DELETED from NodeBB" (`scripts/deploy-wiki.sh:148-158`). Read together, the operator is told zero pages will be deleted on a run that would delete 1213. ## Cause `planNodeBBDeploy` (`internal/topdata/wiki_deploy.go:498-506`) adds the reset plans straight to `result.Purged` and then discards the manifest: ```go resetPlans, purged, err := planManagedNamespaceReset(opts, client, progress) ... result.Purged += purged manifest = wikiDeployManifest{Version: "nodebb-v1", Pages: map[string]wikiDeployManifestPage{}} ``` Nothing touches `result.Stale`, because the reset purge never goes through stale computation at all. It is a second, independent deletion path. ## The documented model says otherwise sow-topdata's wrapper documents the contract it was given, at `scripts/deploy-wiki.sh:32-36` and `:92-94`: "the deployer deletes only pages the manifest says we wrote", and "crucible computes the stale set from the deploy manifest only: no manifest => nothing is stale => archive/purge delete nothing". Under `--reset-managed-namespaces` neither statement holds. That repo built a fail-closed gate (`require_page_history`, `deploy-wiki.sh:99-117`) on top of the assumption, and its recovery advice at `:102` tells operators to re-seed with `RESET=1` — the exact flag that bypasses the model the gate protects. ## Scope of the reset enumeration Worth stating plainly in the docs, because it is easy to assume otherwise: `planManagedNamespaceReset` (`internal/topdata/wiki_deploy.go:685-730`) calls `client.listNamespacePages(cid)` and queues **every** topic it returns. There is no filter on the managed-region marker that `wiki/wiki.yaml` configures (`page_marker_prefix: sow-topdata-wiki`). So the reset purges the whole category, including topics crucible never wrote. In the run above that is the 13-topic gap between 1213 purged and 1200 recreated. That may well be the intent of a re-seed. The problem is that no output distinguishes "1200 pages I own" from "13 pages I have never seen", and the count that would have flagged it reads 0. ## Suggested fix Report the reset purges in a field that the preview's destructive-policy warning actually covers — either fold them into `stale`, or print a distinct line naming them as a namespace reset and how many of them are unrecognized. The unrecognized subset is the number worth surfacing, since those are the deletions a re-seed cannot undo. Found while working ShadowsOverWestgate/sow-topdata#198.

archvillainette added the Kind/Bug label 2026-08-05 15:37:39 +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)