feat(acp): show where reply time goes after an agent @mention - #6637
Open
BradGroux wants to merge 1 commit into
Open
feat(acp): show where reply time goes after an agent @mention#6637BradGroux wants to merge 1 commit into
BradGroux wants to merge 1 commit into
Conversation
Refs block#2386 Co-authored-by: Brad Groux <bradgroux@hotmail.com> Signed-off-by: Brad Groux <bradgroux@hotmail.com>
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
mention_reply_latencysamples.What this measures
This slice measures
harness_relay_receiptthroughharness_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_readandacp_writeobserver events are unchanged and remain outside this new redaction guarantee.Verification
cargo fmt --all -- --checkcargo clippy -p buzz-acp --all-targets --all-features -- -D warningscargo test -p buzz-acp --no-fail-fastwith ambient lazy-pool overrides removed: 673 library tests and 9 pool-lifecycle tests passed.just cipassed 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 failureChannelDetailPage keeps follow mode off while a tall newest message stays visibleatmobile/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.