Skip to content

fix(registry): writer anchor-adopt promotes contributed rid to authoritative#3380

Merged
bokelley merged 1 commit into
mainfrom
bokelley/writer-anchor-adopt-promotion
Apr 28, 2026
Merged

fix(registry): writer anchor-adopt promotes contributed rid to authoritative#3380
bokelley merged 1 commit into
mainfrom
bokelley/writer-anchor-adopt-promotion

Conversation

@bokelley

Copy link
Copy Markdown
Contributor

Summary

Found via escalation #287 (wheelrandom.com): the publisher's adagents.json is valid and anchored, but the registry resolves 0 authorizations.

Root cause

When projectPropertyToCatalog adopts a foreign rid via Rule 4 (publisher anchors via a domain identifier under their own host), the UPDATE refreshes adagents_url and property_id via COALESCE — but leaves source='contributed' and created_by='community:<pub>' (or whatever pipeline previously owned the rid).

The auth projection's slug-resolution query then looks up:

WHERE created_by = 'adagents_json:<pub>' AND property_id = ANY([...])

It returns zero rows for the just-adopted rid → targets.length === 0 → no CAA insert → no authorization.granted event. The authorized_agents[] entries silently drop.

This is exactly what wheelrandom.com hit: a contributed row from earlier enrichment was sitting at domain:wheelrandom.com, the manifest came in with a clean property + slug + auth, the property got the slug COALESCE'd in but the auth never landed.

Fix

Two extra columns on the adopt-path UPDATE:

  • source = 'authoritative'
  • created_by = expectedCreatedBy (= 'adagents_json:<pub>')

Idempotent for own re-crawls (when matchedCreatedBy === expectedCreatedBy it's a no-op).

Test

registry-catalog-agent-auth-writer.test.ts:

  • Pre-seed catalog row with source='contributed' and created_by='community:<pub>'
  • Pre-seed identifier domain:<pub> pointing at the row
  • Crawl adagents.json with same domain identifier + a property slug + an auth referencing the slug
  • Assert: rid is reused (no duplicate row), source promoted to 'authoritative', created_by rebound, auth projection lands a CAA row referencing the promoted rid.

61/61 tests pass across writer + reader baseline + reader cutover.

Test plan

  • Merge → deploy → re-trigger POST /api/registry/crawl-request {domain: wheelrandom.com}
  • Watch /api/registry/feed?types=authorization.* for the authorization.granted event
  • Confirm resolve_property for domain:wheelrandom.com returns the property + the agent

Refs #3177.

🤖 Generated with Claude Code

…itative

Found via escalation #287 (wheelrandom.com). Publisher's adagents.json was
valid and anchored, but registry showed 0 authorizations.

Root cause: when projectPropertyToCatalog adopts a foreign rid via the
publisher-anchor path (Rule 4), the UPDATE refreshed adagents_url +
property_id only — leaving source='contributed' and created_by='community:foo'
(or whatever pipeline previously owned the rid). The auth projection's
`WHERE created_by = 'adagents_json:<pub>' AND property_id = ANY(...)` then
returned zero rows, and authorized_agents[] entries silently dropped.

Fix: also set source='authoritative' and created_by=expectedCreatedBy on the
adopt path. The publisher with a matching anchor is now the source-of-truth
pipeline for this property; its created_by should reflect that. Idempotent
for own re-crawls (the SET is a no-op when matchedCreatedBy already equals
expectedCreatedBy).

Test added (registry-catalog-agent-auth-writer.test.ts): pre-seed a
'contributed'/'community:<pub>' catalog row + identifier, then crawl an
adagents.json that references the same domain. Asserts the rid is reused,
source promoted to 'authoritative', created_by rebound, and the auth
projection lands a CAA row referencing the promoted rid.

Refs #3177.
@bokelley bokelley merged commit 2a27321 into main Apr 28, 2026
13 checks passed
@bokelley bokelley deleted the bokelley/writer-anchor-adopt-promotion branch April 28, 2026 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant