Skip to content

feat(acp): show where reply time goes after an agent @mention - #6637

Open
BradGroux wants to merge 1 commit into
block:mainfrom
BradGroux:agent/mention-reply-latency
Open

feat(acp): show where reply time goes after an agent @mention#6637
BradGroux wants to merge 1 commit into
block:mainfrom
BradGroux:agent/mention-reply-latency

Conversation

@BradGroux

Copy link
Copy Markdown
Contributor

Note: This is a replacement for PR #2408, which was accidentally closed when branches were force-pushed after a commit identity rewrite. The changes are identical, rebased onto the latest main.

Refs #2386.

Why this PR exists

Four simple agent replies in #2386 took 13–31 seconds, but the available event timestamps only showed the beginning and end of each turn. That left no way to tell whether the delay happened in queueing, runtime startup, model work, or reply publication.

This PR adds the first in-process timing slice after Buzz receives the mention.

What changed

  • Record process-local monotonic boundaries for relay receipt, queue admission, ACP session resolution, prompt dispatch, first semantic model or tool output, first reply fan-out, and turn completion.
  • Correlate those boundaries into content-free mention_reply_latency samples.
  • Report rolling warm/cold p50, p95, and max summaries for each stage.
  • Let observer-enabled mention subscriptions receive self-authored kind-9 replies for telemetry while preserving the normal self-dispatch guard.
  • Prefer signed parent/root correlation over whichever turn is currently active, so delayed relay fanout cannot be assigned to a newer turn.
  • Treat unmatched signed thread tags as authoritative negative evidence instead of falling back to the active turn.
  • Use channel fallback only for replies with no signed thread tags, and fail closed when more than one turn is possible.
  • Document a deterministic check and an opt-in warm/cold live benchmark.

What this measures

This slice measures harness_relay_receipt through harness_relay_fanout. It does not claim sender-publish-to-recipient-render timing.

Durations come from one process-local monotonic clock. RFC3339 and Nostr timestamps are correlation metadata only.

The new semantic timing events contain identifiers, path classification, durations, and sample counts. They do not include message content, prompts, model output, credentials, or tool arguments. Existing raw acp_read and acp_write observer events are unchanged and remain outside this new redaction guarantee.

Verification

  • cargo fmt --all -- --check
  • cargo clippy -p buzz-acp --all-targets --all-features -- -D warnings
  • cargo test -p buzz-acp --no-fail-fast with ambient lazy-pool overrides removed: 673 library tests and 9 pool-lifecycle tests passed.
  • just ci passed formatting, workspace strict Clippy, Desktop check, Tauri strict Clippy, web check, mobile format/analyze, Rust suites, 3,885 Desktop tests and build, 2,047 Tauri library tests plus 3 diagnostics, and the web build. The final mobile suite reached 1,021 passed and 1 skipped, then reproduced the unchanged current-main failure ChannelDetailPage keeps follow mode off while a tall newest message stays visible at mobile/test/features/channels/channel_detail_page_test.dart:1053. This branch has no mobile diff.

What remains

#2386 should stay open until the outer sender-publication and recipient-render or relay-acceptance boundaries are measured, hosted warm/cold baselines and explicit budgets exist, and a scheduled or blocking regression job is in place.

Refs block#2386

Co-authored-by: Brad Groux <bradgroux@hotmail.com>
Signed-off-by: Brad Groux <bradgroux@hotmail.com>
@BradGroux

Copy link
Copy Markdown
Contributor Author

This is a replacement for #2408, which was accidentally closed when branches were force-pushed after a commit identity rewrite. Prior review comments and feedback are preserved on the old PR:

#2408

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant