block / block/buzz

buzz-acp: most log targets are invisible under the RUST_LOG the desktop injects

Open
#7,290 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
32.7k
Forks
4.3k
Avg merge
1d 13h
Merged PRs (30d)
253

Description

## Summary

`buzz-acp` logs 102 call sites under bare targets (`pool::prompt`, `acp::wire`, `canvas::fetch`, …). `EnvFilter` matches targets by `::`-separated prefix, so none of them match a `buzz_acp` filter — and `buzz_acp` is the only filter a managed agent ever runs with.

The result is that a managed agent's log records which channels it subscribed to, but not what it then did with them.

## Why every managed agent hits this

Two independent places pin the filter to `buzz_acp`:

- the harness default: `EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new("buzz_acp=info"))` in `lib.rs`
- Buzz Desktop injects `RUST_LOG=buzz_acp=info` into every managed agent, which takes precedence over that default

Verified on a running agent:

```
$ ps eww -o command= -p | tr ' ' '\n' | grep RUST_LOG
RUST_LOG=buzz_acp=info
```

So changing only the harness default does not fix it — the environment wins. I tried that first.

## Scope

19 distinct targets, 102 call sites, all invisible in a managed agent:

| target | call sites |
|---|---:|
| `pool::prompt` | 17 |
| `canvas::fetch` | 11 |
| `acp::wire` | 11 |
| `pool::model` | 5 |
| `pool::effort` | 5 |
| `pool::permission` | 4 |
| `pool::metrics` | 4 |
| `engram::core` | 4 |
| `acp::usage` | 4 |
| `acp::update` | 4 |
| `acp::permission` | 3 |
| `acp::tool`, `acp::cancel`, `observer` | 2 each |
| `acp::thought`, `acp::stream`, `acp::session`, `acp::plan`, `acp::init` | 1 each |

By file: `pool.rs` 48, `acp.rs` 31, `lib.rs` 1, `engram_fetch.rs` 1.

## What this costs in practice

These are the lines an operator needs when something goes wrong, and none of them are emitted:

- `pool::model` / `pool::effort` — why a model switch or an effort level did not apply
- `canvas::fetch` — why a channel canvas is missing from the prompt
- `engram::core` — why core memory was not injected
- `acp::wire` — the adapter conversation itself
- `pool::prompt` — what was actually dispatched

Nothing is broken at runtime; the information simply never reaches the log. It reads as "the agent did nothing", which is indistinguishable from an actual stall.

## Repro

1. Run any managed agent from Buzz Desktop
2. Mention it so it takes a turn
3. `grep 'pool::' ~/Library/Application\ Support/xyz.block.buzz.app/agents/logs/*.log`

Zero matches, though the turn ran.

## Suggested fix

Prefix the targets with the crate path — `buzz_acp::pool::prompt`, `buzz_acp::acp::wire`, and so on. That keeps the finer granularity for anyone who sets `RUST_LOG` deliberately (`RUST_LOG=buzz_acp::acp::wire=debug` still works), while making the lines visible under the filter the desktop already imposes, with no configuration change on either side.

Widening the desktop's injected `RUST_LOG` would also work, but it silently depends on the desktop and the harness agreeing on a list of target names.

Happy to send a PR if the prefix approach looks right to you.

## Environment

macOS 15, Buzz Desktop built from `main`, `buzz-acp` from the same tree.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.