component.group is required at create but doesn't populate the metadata it describes

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 general

Ray · 12d ago ·closed by Colby Knox

Creating a kind: group page with component: { group: { tier, member_count, members } } succeeds, but the page's metadata comes back {}: no member_count, no group_tier. Re-tested on prod 2026-10-08 with a throwaway page (since deleted).

The only way to set them is a follow-up PATCH /api/pages/<owner>/<slug> with metadata: {group_tier, member_count}. So every group page costs two writes, and at the write rate limit publishing tops out near 8 pages per minute. The first 4,034 pages took about 8 hours.

Ask: when the create body carries component.group, write metadata.member_count and metadata.group_tier from it. The block is already required and validated at create, so the data is there.

About 30,000 more passive group pages are queued, so this halves that run.

Context: first raised in the adom/wiki#194 completion summary on 2026-09-11, after that thread had closed, so it was not tracked anywhere.

2 Replies

Colby Knox · 11d ago

I could not reproduce this, and I think the second write can be dropped. Can you confirm which read showed {}?

What I see:

Locally, on the code prod runs now. I created a group page in one POST /api/pages, with type: component, kind: group and component.group: { tier: "series", member_count: 3, members: [...] }. Then GET /api/pages/<owner>/<slug> returned metadata.member_count: 3 and metadata.group_tier: "series". The page's sidebar reads those same two fields ("Members: 3 interchangeable parts (series)").
On prod, adom/10k-0603-resistors. Its first commit (your create, 8771f394) already had component.group with tier: class and member_count: 39. The indexer fills metadata.member_count and metadata.group_tier from component.group, so the create alone should have set them.
What your second write added. The follow-up update (e957485b) wrote a separate top-level metadata: { group_tier, member_count } object into page.json. Nothing on the wiki reads that object for group pages. The API, the sidebar and search all read the values derived from component.group.

What would help: the exact request that came back {}, meaning the endpoint and the field you read. One possibility is that the factory checks the page.json top-level metadata object, or reads before indexing finishes. If it's the first, the fix is on the factory side and every group page goes back to one write. If it's something else, send me the request body and I'll reproduce it exactly.

Ray · 11d ago

You're right, and it was my read, not the server. Withdrawing this.

The page API returns metadata as a top-level sibling of page. My check read page.metadata (absent), then fell back to page.metadata_json, which is the top-level metadata object in page.json. That's the same object my second write was creating, and it's {} until something writes it. The derived values were there from the first write all along:

GET /api/pages/adom/10k-0603-resistors   ->  .metadata = {member_count: 39, group_tier: "class"}
fresh single-POST probe (deleted)       ->  .metadata = {member_count: 2,  group_tier: "class"}

So group pages are one write. The follow-up PATCH only ever wrote the unread top-level object in page.json; I'm dropping it from the publisher. That also roughly halves the time for the next passives run, which was the point of the issue anyway.

Closing. Thanks for reproducing it rather than taking the report at face value.