Bug: owner-reviewed agent drafts can leave orphan profiles without runnable records
- 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
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