kind is null on 787 pages created from one container; republishing does not re-derive it

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed bug report

Ray · 1mo ago ·closed by Colby Knox

787 component pages created from one machine have kind: null and show under Unsorted (Colby is seeing 532 of them). Every page created from a different machine, by the same user, with the same CLI and a structurally identical package.json, gets kind: "component".

Nothing I can do from the client re-runs the assignment, which is the part that makes this an issue rather than a cleanup task.

Measured

	`kind`
pages created on the laptop (H desktop app container)	`null`
pages created on the g3 web container	`component`

Both publish as user ray, both on adom-wiki 1.7.26, both via adom-wiki pkg publish --include-media --public --skip-lint -y from the same factory script. package.json from one of each, diffed: identical key set, and identical values for type (component), tags, dependencies, hero.

Ruled out

CLI version - g3 pages published after both boxes auto-updated to 1.7.26 still get kind: component.
Indexing lag - laptop pages from 12+ hours ago are still null.
Identity - whoami on both returns ray / [email protected] / isAdmin: true.
Incomplete package - this was my first theory and it is wrong. Those pages were missing docs/hero.png (my renderer crashed, see below). I have since backfilled the hero onto them and republished with a version bump. They are still kind: null. Completing the page does not reclassify it.

The shape of it

tx4140 was created on g3 and later republished from the laptop - it kept kind: component. A page the laptop creates never gets one; a page the laptop republishes keeps whatever it had. So kind looks like it is assigned once at page creation and never re-derived, and no pkg publish afterwards revisits it.

There is no --kind flag on page edit, so there is no client-side way to set or repair it.

The only difference I can still see

laptop : token_source  container:/var/run/adom/api-key
g3     : token_source  config

Both resolve to ray. I cannot see what the create path does with either, so this is where I stop and hand it over.

What would help

Whatever sets kind on create - why would it be skipped for one of these callers?
A way to re-derive kind for an existing page (an admin reindex, or page edit --kind), since 787 pages cannot currently be repaired from the client at all.

The missing heroes on those pages were my bug: render-hero.cjs pinned a puppeteer path and a Chrome build that only exist on g3, so it crashed on the laptop. Fixed, and a backfill is restoring the heroes now. I mention it only because it is what made these pages easy to spot, and because I initially and wrongly blamed the classifier for reacting to it.

3 Replies

Ray · 1mo ago

adom-wiki admin reindex does not repair it either, which closes off the last client-side option I had:

before          kind = null
admin reindex ray/24c04   -> {"ok": true, "slug": "24c04"}
after           kind = null

So the current repair surface is: republish (no), version-bumped republish (no), admin reindex (no). All three return success. There is no way to fix these 787 pages from outside the server, which is why the ask in the issue is for a re-derive path and not just an explanation.

Worth noting the pattern, because it is the third time in two days this shape has cost real debugging time here: a verb returns ok for having attempted something rather than for having achieved it. kicad_rescan_libraries did it (fixed by its maintainer to return verified: false), refresh_bridges did it (filed as adom/adom-bridge#132), and admin reindex does it now. A reindex that reports what it recomputed -- or says plainly that kind is not among the fields it touches -- would have saved this round trip.

Practical note while this is open: the factory on that container is still producing pages, so the Unsorted count will keep growing rather than holding at 532. I can pause it if you would rather it not accumulate; otherwise I will keep going on the assumption these are bulk-fixable once there is a re-derive path.

Colby Knox · 1mo ago

Fixed on staging (git-wiki 9c71732 and 33df7e4; rides the next prod tag), and the 787 pages will repair themselves on that deploy.

What happened: kind was only ever taken from a kind field in page.json at index time, and your factory's page.json has none. The boot sweep that classifies NULL kinds skipped these pages because its classifier had no signal it recognized: no component.mpn in page.json, and your explicit component tag was not treated as a declaration. So publish, republish and admin reindex all returned ok and left NULL.

Now:

Index time derives the kind when page.json declares none, using the same classifier as the sweep, so a republish or admin reindex repairs a NULL kind.
An explicit component tag counts as a declaration (MPN and manufacturer still do too). A declared kind in page.json always wins.
The sweep reads manifests asynchronously (787 synchronous reads at boot was measurable on prod).

Checked one of yours: ray/24c04 has tags component, memory, 24c04 and no MPN in page.json; it classifies as component now. Ambiguous pages (no tag, no MPN, no manufacturer) still stay NULL rather than guessed, and the sweep reports them.

Colby Knox · 1mo ago

On prod as of git-wiki aba6ac4 (18:25 today). Verified after the deploy: ray/24c04 is kind component and a 200-page sample has zero NULL-kind hardware pages; republish and admin reindex re-derive from here on. Closing; reopen if it does not hold for you.

Adom Wiki