Files
buzz/crates
Will Pfleger 121e4b3ce7 fix(desktop): exclude archived agents from nest, order regeneration (#5905)
The managed "Active Agents" table in `~/.buzz/AGENTS.md` was rendered
from every managed-agent record with no filtering, so archived duplicate
instances kept appearing under the active relay's header. This scopes
the roster to identity-active agents and makes regeneration safe under
concurrency.

## Roster filter: identity-archive only

`render_dynamic_section` now drops only records whose pubkey is present
in the relay's `kind:13535` archive snapshot. Local records can't tell
they're archived — they all carry `is_active: true` (that flag is a
*definition*-archive, not an identity-archive), so archive truth lives
only relay-side. The read **fails open**: an unreachable relay yields an
empty set and hides no one.

There is deliberately **no** relay-scope filter. `relay_url` is a legacy
creation-era field that `effective_agent_relay_url()` ignores — every
agent is eligible on every community, and snapshot-imported records
store `relay_url: ""` by design. Filtering on it would hide valid,
runnable agents after a workspace switch or import. Foreign-relay relic
records leave the table via record deletion, not code.

## Regeneration on archive / unarchive

`archive_identity` and `unarchive_identity` submitted the relay event
and returned without refreshing `AGENTS.md`, unlike the ~20 other
mutation sites that call `try_regenerate_nest`. A just-archived agent
therefore lingered on the roster until an unrelated edit or the next
launch. Both commands now trigger a regeneration after a successful
submit.

Regeneration is bound through a `NestRegenTrigger` trait rather than
constructing the `try_regenerate_nest` callback at the Tauri-command
delegation site. The command cores take `regen: &impl NestRegenTrigger`
and own the `|| regen.trigger()` binding; the thin wrappers only pass
`&app` (whose `impl` calls `try_regenerate_nest`). This puts the regen
wiring inside the unit-tested core — a `CountingRegen` double proves
each core fires exactly one regeneration — instead of an untestable seam
where a wrapper could silently lose the refresh while the suite stayed
green. The regen races the relay's `kind:13535` snapshot update, so it's
best-effort and fail-open — a stale render self-heals on the next cycle.

## Ordered regeneration

`try_regenerate_nest` previously spawned unconstrained tasks that each
snapshotted state, awaited two relay requests, then wrote — so a slow
pre-edit generation could overwrite a newer one. Boot made this
deterministic: the boot regen races the `apply_workspace` regen, and the
fallback-relay render could finish last.

`NestRegenGate` fixes this with a single `highest_requested` watermark.
A monotonic generation is claimed *synchronously* at request time
(encoding call order) and advances the watermark under one lock; the
spawned task carries its generation and, at commit, reads the watermark
under that same lock — the compare-and-write is atomic with no await
held across it. A generation whose number is below the current watermark
drops its result instead of rolling the file back.

Gating on highest-*requested* rather than highest-*written* is the
load-bearing choice: if a newer generation is requested but then fails
its relay reads, an older in-flight generation must **not** publish its
now-obsolete roster. Behavior delta: once a newer regeneration has been
requested, no older generation will ever write; if that newer generation
fails, the file is left as-is and self-heals on the next trigger rather
than regressing to a stale snapshot. This is an ordered,
latest-request-wins gate — not a work coalescer: superseded generations
still perform their relay reads and drop the result at commit time.

The gate's commit lock is acquired with a poison-to-`io::Error` mapping
rather than `expect()`, so a poisoned lock degrades to the same
warn-and-continue path as any other commit failure instead of panicking
the desktop process (a best-effort housekeeping write must never take
down the app).

## One relay target per regeneration

A regeneration read the workspace relay override three times — the
NIP-11 signer in `fetch_relay_self`, the snapshot query in
`query_relay`, and the rendered footer — so a workspace switch
mid-flight could pair one relay's advertised signer with another relay's
snapshot, fail open, and render archived agents as active.
`capture_relay_target` now resolves the effective relay (WebSocket +
HTTP API base) once, before any network work, and
`fetch_archived_pubkeys_at` threads that single target through both the
NIP-11 fetch and the `/query`; the footer renders the same target.
Signer, snapshot, and footer always belong to one relay.

## Monotonic archival snapshot publishing

`publish_nipia_archival_list` stamped its `kind:13535` snapshot with a
whole-second `created_at`. A rapid archive→unarchive within the same
second produced two events whose NIP-16 replaceable-event tie-break
(higher event id wins) could strand the older, stale archive state as
canonical. Publishing now uses a bounded retry that re-reads current
archive state and rebuilds the snapshot each attempt, so the published
list reflects the latest intended state rather than a fixed same-second
race loser. After the attempt budget (8) is exhausted the publisher
`bail!`s; the sole caller treats that as a `warn!` side effect and
continues, matching the surrounding best-effort submit path.

## Test-file split

The renderer, `upsert_managed_section`, and the regeneration-gate tests
moved to `nest/render_tests.rs` so each test file stays under the
repository's 1000-line ratchet.

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Hayt <9e1c23a3fd83f61da34420e4e88ff1b16e45cafcc0cd9019eb07d4ecfa8ca9b0@buzz.block.builderlab.xyz>
Co-authored-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Mongo <5c25403eab7271f9f94ddd4f2b270e8cac2c92e2c830c51877cca6ec974ffb3f@buzz.block.builderlab.xyz>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
2026-08-18 18:26:35 -04:00
..