buzz-acp channel discovery 404s — relay has no GET /api/channels route, and the harness reports the failure as `discovered 0 channel(s)`

[andali]

buzz-acp channel discovery 404s — relay has no GET /api/channels route, and the harness reports the failure as discovered 0 channel(s)

Summary

Update: root cause identified in the comments — GET /api/channels returns 404 on the relay; the harness reports this as zero channels rather than an error.

On a self-hosted relay built from main, managed agents never subscribe to any
channel. The harness logs discovered 0 channel(s) and
no channel subscriptions resolved — agent will sit idle on every start, even
though the relay itself confirms the agent is a relay member and a member of
the channel. @mentions are therefore silently dropped and no agent ever
responds.

The desktop app shows a non-zero channel count for the same agent, so the UI and
the harness's discovery query disagree.

Environment

• Host: WSL2, Ubuntu 24.04.3 LTS (kernel 6.6.87.2-microsoft-standard-WSL2)
• Buzz: built from source, main, cloned 3 August 2026
• Relay: local, just dev, ws://localhost:3000
• Community: seeded localhost:3000 at first start
• Agent: Fizz — one of the default Welcome Team agents created by onboarding
• Runtime: claude-agent-acp v0.64.2 (Claude Code, installed via the app's
  harness setup page)
• Agent pubkey: d00fe41a4d443c47fe7870f665f19a9c9d1e108c3cc4149c75d3c277f4044464

Expected

The harness discovers the channels the agent belongs to, subscribes, and
responds to @mentions from its owner.

Actual

Every start ends with:

INFO buzz_acp: connected to relay at ws://127.0.0.1:3000
INFO buzz_acp: subscribed to membership notifications
INFO buzz_acp: owner resolved from BUZZ_AUTH_TAG: c26482b9…fd97
INFO buzz_acp: agent owner: c26482b9…fd97
INFO buzz_acp: relay observer enabled
INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved — agent will sit idle
INFO buzz_acp: presence set to online

The agent pool initialises cleanly (agent_pool_ready agents=10), the ACP
handshake succeeds for all ten subprocesses, the relay connection succeeds, and
the owner resolves. Only discovery returns nothing.

Evidence that the memberships exist

Channel membership — the agent is present with role: "bot":

$ buzz-cli channels members --channel adafd400-706c-5c13-bf02-bc2ebb45b1c7
[{"pubkey":"c26482b9…fd97","role":"owner"},
 {"pubkey":"d00fe41a…4464","role":"bot"}]

Relay membership — added manually via buzz-admin:

$ buzz-admin list-members
pubkey                    role     added_by   created_at
d00fe41a…4464             member   -          2026-08-03T12:30:11Z

Channel announcement events are present:

$ buzz-admin reconcile-channels
Reconciled 0 channels (3 already had events, 3 total).

Desktop UI: the agent's profile panel shows Channels 2.

Steps to reproduce

1. Clone main, just setup && just build, just dev.
2. Complete onboarding: create identity, install the Claude Code ACP adapter,
   join ws://localhost:3000 via Join a community, accept the default
   Welcome Team agents.
3. Start Fizz from the Agents panel.
4. Open the Harness Log.

Observed: discovered 0 channel(s) on every start.

Things tried, each followed by a full agent restart

Action	Result
Restart agent alone (×3)	discovered 0
Add agent to public #general via the desktop UI	discovered 0
buzz-admin reconcile-channels	3 channels already had events; discovered 0
Set BUZZ_RELAY_PRIVATE_KEY, restart relay, buzz-admin add-member	discovered 0

Timing was ruled out: relay membership was written at 12:30:11Z and the
harness restarted at 12:30:54Z, 43 seconds later, still reporting 0.

Notes

• respond_to=owner-only is the default and the owner resolves correctly from
  BUZZ_AUTH_TAG, so the author gate is not the cause — discovery fails before
  any event reaches it.
• The relay was initially running on the hardcoded dev keypair. Setting a stable
  BUZZ_RELAY_PRIVATE_KEY was required before buzz-admin add-member would run
  at all, but did not change the outcome.
• The gap between the UI's channel count and the harness's discovery result
  suggests the two read membership from different places.

Related

Not a duplicate of #2270 (agents deaf to untagged thread replies) or #1743
(mentions lost when the agent is offline) — in both of those the agent has
resolved channel subscriptions. Here it has none.

[andali]

Root cause: the relay has no /api/channels route

Following up on my own report — I think I've found the cause, and it isn't membership.

The buzz-acp README states that the harness discovers channels via GET /api/channels?member=true:

By default, the harness discovers only channels the agent is a member of (GET /api/channels?member=true).

On my relay, that path 404s:

$ curl -s -i "http://localhost:3000/api/channels" | head -5
HTTP/1.1 404 Not Found
vary: origin, access-control-request-method, access-control-request-headers
access-control-allow-origin: *
access-control-expose-headers: *
content-length: 0

?member=true returns an empty body as well.

Meanwhile the underlying query capability does exist — just one layer down, in buzz-db:

crates/buzz-db/src/channel.rs:941: member_only: Option,
crates/buzz-db/src/channel.rs:943: // When member_only is Some(true), restrict to channels where the user
crates/buzz-db/src/channel.rs:947: let membership_clause = if member_only == Some(true) {
crates/buzz-db/src/lib.rs:2304: member_only: Option,

A grep for api/channels across crates/buzz-relay/src/ returns only two comments in metrics.rs referencing /api/channels/{channel_id} as an example route pattern — no route registration.

Caveat on that last point: the 404 is the hard evidence. The grep is suggestive but not conclusive, since routes may be composed via nesting (nest("/api", …) + route("/channels", …)) in a way a literal string search would miss. Someone with knowledge of the routing setup should confirm whether the route is genuinely absent or registered under a different path.

Either way, the client and server disagree about where channel discovery lives, and the harness gets a 404.

Secondary bug: the harness reports a 404 as "zero channels"

buzz-acp translates the failed request into:

INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved — agent will sit idle

There is no indication that a request failed. This is why the misconfiguration looked like a membership problem — it took several hours and four wrong hypotheses to find, when a logged 404 from GET /api/channels would have made it immediate.

Suggested: log the HTTP status and URL when discovery returns a non-2xx, and surface it in the agent's status in the desktop app rather than reporting a successful discovery of nothing.

What this explains
Why relay membership, channel membership, and reconcile-channels all had no effect — none of them are reachable through a route that doesn't exist.
Why buzz-cli channels list works fine (returns all three channels, authenticated) while the harness sees none: the CLI reaches channels by a different path.
Why the desktop UI shows a non-zero channel count for the same agent — it reads from its own state, not from this endpoint.

[dexsims7-jpg]

Narrowing this on a self-hosted dev relay (commit ac4fa13b, v0.5.3, macOS).

Documentation correction first: ACP startup discovery is an authenticated POST /query for kind 39002 with a single #p value — not GET /api/channels?member=true. That line in crates/buzz-acp/README.md is stale.

The underlying persisted membership, channel, event, and mention-index data are verified intact for agent 3d4cd8dbd8673d29ea9995364ab2a9d52dba39e12bfc4fc0a0b1c60af3e64124 in community 7ec0a5a3-d0eb-4158-ba45-6896e92166cf:

• channel_members: 3 rows, removed_at NULL
• channels: all 3 corresponding rows live (deleted_at NULL)
• events: 4 live kind-39002 events (5 correctly soft-deleted); the agent appears in the p tags of 3 — 8fa8a373 (member), adafd400 (bot), 47da111f (bot)
• event_mentions: exactly 3 rows for that pubkey, one per channel, all with event_kind = 39002, joined to live events
• Owner resolves from BUZZ_AUTH_TAG and matches the owner p tags

The #p filter is SQL-pushed through event_mentions (crates/buzz-db/src/event.rs:371), and those index rows are present and correct. Yet buzz-acp logs discovered 0 channel(s) on every start (6+ harness restarts, 2 app restarts).

With the mention index ruled out, the leading remaining candidate is the accessible-channel scope that POST /query resolves for the authenticated agent pubkey and applies to the SQL (crates/buzz-relay/src/api/bridge.rs:961, 1004). Please log or inspect that resolved channel set and the bridge /query result_count (bridge.rs:923). The three corresponding channel rows are live and the agent has active channel_members rows, so the resolved set should contain all three UUIDs.

Workarounds confirmed non-viable:

• BUZZ_ACP_CHANNELS intersects with discovered channels and cannot seed an empty result (config.rs:1233).
• BUZZ_ACP_SUBSCRIBE=config ignores --channels and exits status 1 without a buzz-acp.toml.

[jonesmikayla1020]

数据库迁移兼容旧版本吗 💡

[andali]

Thanks — and my apologies for the misdiagnosis. I built the root-cause comment on
the GET /api/channels?member=true line in crates/buzz-acp/README.md after a
grep of the harness source came back empty. Curling that path returned a 404,
which fit, but I was testing an endpoint nothing calls. Noting for anyone reading
the thread later: that README line still says "Channel discovery — Queries the
relay REST API for accessible channels," while AGENTS.md states that
get_channels resolves a user's channels from the d tag of their kind:39002
events. Worth reconciling.

New data point: the same setup works against a Block-hosted relay

After filing, I connected the same desktop client to a Block-hosted community
and the agents worked immediately.

	Self-hosted	Block-hosted
Relay	ws://localhost:3000 (built from main, 3 Aug)	wss://<name>.communities.buzz.xyz
Result	discovered 0 channel(s)	discovered 1 channel(s) + subscribed to channel …

Everything else was held constant:

• Same desktop build, same session — switched community via Settings → Hosted
  communities, no reinstall
• Same Nostr identity (paired, not regenerated)
• Same runtime: claude-agent-acp v0.64.2 via the app's harness setup
• Same default Welcome Team agents (Fizz / Honey / Bumble)
• Same agent pool config (agents=10, subscribe=Mentions, dedup=Queue)

The channel UUIDs are also identical across both communities — adafd400-… and
47da111f-… appear in my local relay and in the hosted one, since they're
name-derived. So this is the same scenario with the same default channels,
differing only in which relay serves the query.

On the hosted relay, an @mention produced a correct tool-using reply within about
a minute (the agent ran the Buzz CLI and listed the channels it could see).

That should narrow the search: whatever the accessible-channel scope resolves
from, it resolves correctly under the hosted relay's configuration and returns
empty under a stock just dev self-host. Comparing the two configurations may be
faster than instrumenting bridge.rs from scratch.

Documented workaround also fails

The hermes-buzz-bridge README advises that if startup reports
discovered 0 channel(s), you add the agent's public key to a channel with role
bot and restart. My agent already had role: "bot" in channel_members
(posted in the original report) and still discovered 0 across six restarts. So
that workaround doesn't hold for this failure mode either.

Silent failure stands regardless of endpoint

My endpoint diagnosis was wrong, but the secondary point survives it: whatever
POST /query returns — empty result, error, or non-2xx — the harness logs it as

INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved — agent will sit idle

with no indication that anything failed. That's what sent me down four wrong
hypotheses (channel membership, relay membership, reconcile-channels, timing)
before looking at the transport at all. Logging the result_count and status at
INFO — the same value requested for bridge.rs:923 — would make this
self-diagnosing.

Not yet tested

v0.5.4 shipped 2026-08-03 18:09 UTC, after both my session and ac4fa13b. I
haven't retested against it. Happy to, if it would help.

Environment for this comment: WSL2 / Ubuntu 24.04.3, self-hosted relay built from
main cloned 3 Aug 2026; hosted community created 3 Aug 2026.

[justanotherkevin]

Adding a second data point on this — I hit a related but distinct failure
mode on the same code path (HarnessRelay::discover_channels() →
POST /query), on main.

Where the reports above see a silent discovered 0 channel(s) (query
succeeds, returns nothing), mine was an outright failure that crashed the
whole harness process:

WARN buzz_acp::relay: subscription membership-notif closed by relay: error: database error
WARN buzz_acp::relay: subscription agent-observer-control closed by relay: error: database error
Error: channel discovery error: HTTP error: POST /query returned HTTP 404 Not Found

No further log lines follow that — compare to a normal shutdown, which logs
shutting down → shutdown: waiting for in-flight prompts → presence set to offline → buzz-acp stopped. This just dies. A direct POST /query
against the same relay moments later returned the expected
401 missing Nostr auth (i.e. the route was reachable and behaving normally
again), so in my case it was a transient blip on the relay side, not a
persistent condition — but the harness had no way to recover from it short
of a manual stop/restart.

This doesn't explain the silent-zero-channels case discussed above —
that looks like the deeper issue (bridge.rs accessible-channel scope
resolution returning nothing despite live membership data), which a retry
wouldn't fix if it's a persistent bug rather than a transient failure. But
the two share a root cause of "channel discovery has no error resilience at
all" — a transient POST /query failure here is immediately fatal
(crates/buzz-acp/src/lib.rs:1429-1432, a bare ? with no retry), even
though the crate already has a bounded-retry pattern for the analogous
WebSocket-connect path (retry_initial_connect +
STARTUP_CONNECT_BACKOFFS, relay.rs:3799).

I put together a small fix for the transient-failure side of this: bounded
retry around discover_channels(), reusing the existing backoff ladder but
without retry_initial_connect's terminal-error short-circuit (which
currently classifies RelayError::Http — exactly the error kind above — as
terminal; correct for the WS-connect call site it was written for, wrong
here). Opened as #4775 — doesn't touch the scope-resolution question you're
investigating above, just stops a transient blip from being an unrecoverable
crash. Confirmed locally: build clean, cargo test -p buzz-acp passes
(82/82 in the relay module including 2 new tests), fmt and clippy
clean.