fix(buzz-waker): install the rustls CryptoProvider before opening feeds

[yjc801]

Summary

buzz-waker was the only binary in this workspace that never installed a process-level rustls CryptoProvider. Without it the daemon starts, validates its watch list, logs buzz-waker: watching agent for each configured agent — and then every watch task panics on its first wss:// connection:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.

main() returns Err, the process exits 1, and Fly restarts it. The result is an endless crash loop that reports a clean, healthy startup right up to the moment it dies. Both ring and aws-lc-rs arrive transitively, so rustls cannot auto-select between them.

Why this was invisible until deployment: a full-workspace cargo build unifies features across every crate, which papers over the ambiguity locally. Dockerfile.waker builds only buzz-waker and buzz-backend-sprites, so there the ambiguity is real. It reproduced on every boot of the Fly app that fly.waker.toml describes (added in #26), which is how it surfaced.

The fix mirrors what every other binary in this repo already does — buzz-relay, buzz-cli, buzz-admin, buzz-dev-mcp, buzz-backend-sprites, and buzz-backend-kubernetes all install the provider at startup for exactly this reason.

The result is ignored rather than unwrapped: the provider is process-level, a second install is a documented no-op, and AGENTS.md forbids new expect() in production paths. That matches the majority pattern in the workspace (5 of the 6 call sites above).

Cargo.lock is included because Dockerfile.waker builds with --locked; without the lock entry the image build fails outright.

Related issue

None found for buzz-waker. This is the same class of bug upstream has fixed repeatedly for other binaries — block#2271, block#2322, block#2455, block#4153, block#5341 — none of which covered buzz-waker, since the crate is fork-only.

Given it has now recurred six times across the workspace, a lint or a shared startup helper is probably the real fix; that felt out of scope for a one-line crash fix, but I'm happy to follow up if a reviewer wants it here.

Testing

Local, all clean for -p buzz-waker:

• cargo build --bin buzz-waker
• cargo fmt -- --check
• cargo clippy --all-targets

On Fly (app buzz-waker, fly.waker.toml + Dockerfile.waker, relay wss://openvelvet.communities.buzz.xyz):

• Before: machine crash-looped on every boot — watching agent logged, then four watch tasks panicked, Main child exited normally with code: 1, reboot, repeat.
• After: daemon boots, completes NIP-42 auth against the relay, and subscribes to its channels with no panic.

No UI change, so no screenshots.

Reviewer notes — two findings not addressed here

Both were found while verifying this fix on the live deployment. Neither is caused by this change, and both are out of scope for it, but they matter to anyone actually running the daemon.

1. Tight re-subscribe loop under relay rate limiting (real bug, unfixed). Once the panic is gone and the daemon reaches the relay, it subscribes to ~20 channels, gets rate-limited, and spins. The relay closes the subscription with rate-limited: quota exceeded; retry in 0s; wake_loop.rs retries immediately by design ("Retry the one subscription immediately"), with no backoff and without reading the relay's retry in Ns hint. Measured 100 re-subscribes in 25 seconds, sustained and not decaying — unbounded load on a shared relay.

I stopped the Fly machine rather than leave it hammering the relay, so the deployed app is currently stopped on purpose. Fixing it means honoring the retry hint with a sensible floor and distinguishing rate-limit closes from ordinary ones — a behavioral change to the reconnect ladder that deserves its own PR and its own review.

2. fly.waker.toml comment references a key that isn't there. fly.waker.toml:28 states "min_machines_running below is what actually keeps it running", but no such key exists in the file. The config's behavior is still correct — with no [http_service] block Fly's autostop path never engages, and [[restart]] policy = "always" covers crash restarts — and min_machines_running is only valid inside an [http_service] block, which this app deliberately omits. So the comment is what's wrong, not the config. Left alone to keep this diff to the crash fix.

🤖 Generated with Claude Code