getDomain always returns agent_count: 0 (only listDomains populates it)

[jiashuoz]

Summary

GET /v1/domains/{domain} always returns agent_count: 0, regardless of how many agents are on the domain. GET /v1/domains returns the correct value for the same domains.

Reproduction

Against production, same account, same moment:

GET /v1/domains            (list)          GET /v1/domains/{domain}  (single)
  sked.mnexa.ai   → 2                        sked.mnexa.ai   → 0
  team.mnexa.ai   → 5                        team.mnexa.ai   → 0
  inbox.mnexa.ai  → 1
  agentdrive.run  → 1

Cause

Domain.AgentCount is only ever populated by ListDomainsByUser. The struct comment says so outright:

// internal/identity/store.go:54
// AgentCount is computed at read time by ListDomainsByUser and is
// ...
AgentCount int `json:"agent_count"`

It's computed inline via a correlated subquery in the list query (store.go:1163, scanned at :1203). LookupDomain — the single-resource path — never selects it, so the field stays at Go's zero value. internal/httpapi/domains.go:173 then maps AgentCount: d.AgentCount unconditionally, serializing that 0 as if it were a real count.

So the value isn't "missing" in a way a client could detect — it's an authoritative-looking 0.

Impact

get_domain is the documented poll target after verify_domain (per the MCP tool description: "this is the poll target after verify_domain"). So the endpoint users are explicitly directed to during domain onboarding reports a permanently wrong agent count.

Concretely misleading in at least two flows:

• Checking whether a domain still has agents before attempting delete_domain — which fails with domain_has_agents. A user reading agent_count: 0 would reasonably conclude the domain is empty and be confused by the rejection.
• Confirming agents were created on a freshly verified domain.

Suggested fix

Either populate AgentCount in LookupDomain with the same correlated subquery the list path uses, or — if the extra join isn't wanted on the hot single-resource path — omit the field from that response rather than emitting a false zero. Silently returning 0 is the worst of the three options.

Found while re-registering domains on a production account.