block / block/buzz

Bug: owner-reviewed agent drafts can leave orphan profiles without runnable records

Open
#5,163 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

## Describe the bug

On Buzz Desktop 0.5.5 for macOS, a batch of owner-reviewed `draft-create` forms appeared to save successfully, but the resulting identities are orphaned: their kind:0 profiles and `bot` channel memberships exist on the relay, while no local managed-agent record, retained kind:30177 head, or durable agent key exists. They are absent from the Agents view, unavailable in Desktop mention autocomplete, and cannot run.

This is distinct from the cross-device mention-only case in #3277: the affected identities are missing from the same Desktop that reviewed and saved the forms, and there is no host runtime left to invoke.

## Observed sequence

1. Agents sent owner-reviewed `draft-create` requests through the supported Buzz CLI flow.
2. The owner reviewed and saved eleven create forms in Desktop 0.5.5.
3. Follow-up `draft-update` forms were also reviewed and saved for those names.
4. After restart, all eleven were absent from the Agents view and mention autocomplete.

The create/update requests were sent close together, but the owner reviewed the forms individually.

## Evidence from the affected installation

- App version/build: `0.5.5` / `0.5.5`, Apple Silicon macOS.
- All eleven active pubkeys have resolving kind:0 profiles and are current `bot` members of the channel.
- Six older duplicate pubkeys are separately archived; the active eleven are not archived.
- `agents/managed-agents.json` contains 17 records, all belonging to the pre-existing seven definitions/instances and older built-in duplicates. None of the eleven pubkeys or names occurs anywhere under the app data directory.
- The active scoped retention databases contain kind:30177 heads only for pre-existing agents (10 and 14 heads respectively); none contains any of the eleven pubkeys.
- The macOS `buzz-desktop` keychain blob exists, but its modification time predates the eleven saves. No key material for those pubkeys was durably added.
- None of the eleven pubkeys has authored a message in the affected channel.
- Re-publishing channel membership events does not help, as expected: membership cannot reconstruct runnable private configuration.

## Expected behavior

Saving an owner-reviewed create form must be atomic from the user's point of view:

1. Either the private key/config, local record, public managed-agent projection/profile, and requested channel attachment all commit successfully; or
2. the save fails visibly and compensates any already-published public profile/membership so no orphan identity remains.

The Desktop should not dismiss the form or report success until durable local/private state is verified. On startup, an owner-authored public profile with no runnable configuration should be surfaced as an explicit recovery/error state rather than silently omitted.

## Relationship to existing work

- #3277 / #4913 cover mentionability of remotely hosted agents. That does not restore a missing host runtime.
- #4999 adds encrypted relay-primary private managed-agent configuration and fresh-device materialization. It appears to be the right prevention/recovery foundation for future creates, but this 0.5.5 incident has no private config event to recover. Please add a create-transaction regression covering interruption or concurrent reviewed drafts, and define upgrade/recovery UX for pre-30179 orphan profiles.

## Suggested regression invariant

After any create command returns success, assert all of the following for the same pubkey:

- the key store can read the generated nsec;
- `managed-agents.json` (or the authoritative successor store) contains the runnable record;
- retained public and private config heads exist as applicable;
- relay profile publication and channel attachment completed;
- a fresh list/refetch displays exactly one agent and can resolve its mention target.

Inject a failure after each persistence/publication phase and assert either full recovery on restart or complete compensation, never a profile-only orphan.

Contributor guide

Open the contributing guide

Research direction

Start by tracing create persistence and publication across agents/managed-agents.json, the key store, retained configuration databases, relay profile publication, and channel attachment. Add the requested interruption or concurrent-draft regression, then verify the invariant: success leaves complete runnable state and failure recovers or compensates without an orphan profile; also review recovery UX for pre-30179 profiles.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, rust
Domain
backend, databases, desktop, testing
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.