fix: scope agent-resolver NEWS_KV writes to requested addresses

[whoabuddy]

Summary

• resolveAgentNames previously wrote every agent in the bulk fetch (up to 1000 entries) to NEWS_KV on every cache miss, even when the caller only asked about 1–2 addresses.
• Scope the kv.put fan-out to the originally-requested addresses; keep the bulk fetch itself as the latency optimization.
• Targets B1 in cloudflare-bill-reduction-tracker-2026-05.md — remaining NEWS_KV writes (~12.3K/h, residual after PR fix: move agent-news rate limits off KV #704/fix: enforce IP bucket before identity rate limits #705 removed rate-limit counters).

Why this is the dominant remaining writer

Inventory: worker-logs/.planning/2026-05-02T2050Z-news-kv-write-inventory.md

resolveAgentNames is called from routes/{signals,correspondents,init,leaderboard,classifieds,agents,brief-compile}.ts. With ~1000 registered agents on staggered 24h TTLs, a single uncached address triggered up to 1000 KV puts. Other writers (single-address resolver, identity gate, SWR locks) are bounded to 1 put per relevant event.

Expected metric movement

Metric	Pre-PR (last 24h)	Target
NEWS_KV writes/h	12.3K	low single-digit K/h (driven by SWR locks + identity gate)
NEWS_KV reads/h	~50K	unchanged
Name resolution correctness	100%	100% (smoke /api/signals, /api/correspondents, /api/init)

Validation window: 24h post-deploy, Cloudflare GraphQL on the production NEWS_KV namespace.

Rollback signal

If we see name-resolution regressions in /api/signals, /api/correspondents, or /api/init (rendered display names suddenly missing for non-requested-but-recently-seen addresses), revert this commit. The previous behavior pre-warmed the entire registry, so any caller relying on a sibling lookup populating its cache implicitly would break.

There are no such callers in the current code — every call site explicitly passes the addresses it cares about.

Test plan

• npm run typecheck passes
• post-deploy smoke: /api/signals, /api/correspondents, /api/init return populated name fields
• Cloudflare GraphQL: NEWS_KV writes/h drops materially in 24h post-deploy window
• Central logs (logs.aibtc.com) clean for agent-news post-deploy

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	agent-news	4436e59	May 02 2026, 11:59 PM

[github-actions]

Preview deployed: https://agent-news-staging.hosting-962.workers.dev

This preview uses sample data — beats, signals, and streaks are seeded automatically.

[Copilot]

Pull request overview

This PR narrows resolveAgentNames KV write behavior so the agent resolver still uses the bulk registry fetch for latency, but only persists cache entries for the addresses the caller actually requested. In the broader codebase, this targets one of the remaining high-volume NEWS_KV write paths without changing the external resolver interface.

Changes:

• Update the batch resolver documentation to reflect that bulk fetches are no longer used to pre-warm unrelated addresses.
• Restrict KV fan-out after a bulk fetch to uncached requested addresses instead of every fetched agent.
• Preserve existing negative-caching behavior for requested addresses that are still unresolved after a complete bulk fetch.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arc0btc]

Scopes resolveAgentNames KV writes to only the originally-requested addresses — correct fix for the bulk pre-warm cost driver.

What works well:

• Logic change is sound: the continue guard on !uncachedSet.has(btcAddr) correctly short-circuits unneeded writes while preserving the bulk fetch as a pure latency optimization
• Moving infoMap.set and uncachedSet.delete before the KV write is the right ordering — local state updated before the async side-effect, which makes the loop easier to reason about
• Negative-caching for unresolved requested addresses (the block after the loop) is untouched — that path still works correctly
• TTL logic (info.name ? CACHE_TTL_SECONDS : NEGATIVE_CACHE_TTL_SECONDS) is preserved for the now-scoped writes
• PR description is thorough: explicit rollback signal, metric baseline, and confirmation that no callers rely on sibling-address cache pre-warming. That last point is the critical invariant here and it's good to see it called out explicitly.

[nit] Planning doc reference in inline comment (agent-resolver.ts:204)
The comment references cloudflare-bill-reduction-tracker-2026-05.md by path. That file will outlive its context, making this comment cryptic to future readers. The surrounding explanation is already clear — consider dropping the doc reference and keeping just the metric reasoning.

Code quality notes:
The refactor is already minimal. Old code had an outer write loop with an inner conditional for the infoMap — new code flips the guard to a continue, which removes the nesting and makes the intent obvious at a glance. No reuse opportunities missed; the uncachedSet was already the right data structure for this.

Operational note: We process all the public agent-news API routes (signals, correspondents, init) daily. The pre-warm behavior was invisible to callers but would have inflated KV write counts on every agent-resolver miss. The scoping to uncachedSet aligns with how every call site already works — each passes exactly the addresses it needs.

[whoabuddy]

Addressed arc0btc's nit in 4436e59 — dropped the planning-doc reference, kept the metric reasoning.