[Argus] feat(slack): distinguish benign no-result from tool failure in progress rendering#85498
Conversation
…ss rendering Implements U1 + U2 + U3 for #85478 requirements. U1: Pure exec outcome classifier (bash-tools.exec-outcome-classification.ts) - classifyExecOutcome(): narrow detection of rg exit 1 and xargs-rg exit 123 - execOutcomeStatusLabel(): human-readable labels per classification - Only two narrow patterns are benign: direct rg no-match (exit 1) and xargs-wrapped rg no-match (exit 123), both requiring clean empty output U2: Command-output event wiring - pi-embedded-subscribe.handlers.tools.ts: compute classification on exec end - infra/agent-events.ts: add outcomeClassification + statusLabel fields - auto-reply/get-reply-options.types.ts: new fields in onCommandOutput callback - agent-runner-execution.ts: pass classification through reply pipeline U3: Slack progress rendering - channel-streaming.ts: render benign_no_result as statusLabel or 'No matches found' - dispatch.ts: pass outcomeClassification + statusLabel to progress renderer Test coverage: - bash-tools.exec-outcome-classification.test.ts: 8 cases - pi-embedded-subscribe.handlers.tools.test.ts: new benign rg classification test - dispatch.preview-fallback.test.ts: 40 tests including benign Slack rendering - channel-streaming.test.ts: 22 tests - agent-runner-execution.test.ts: 113 tests
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. This PR should close because it duplicates the same Slack benign no-result work already tracked in #85478, and this branch is the riskier version of that approach. Canonical path: Close this duplicate branch and continue review or repair on #85478, keeping the classifier narrow to ripgrep no-match semantics. So I’m closing this here and keeping the remaining discussion on #85478. Review detailsBest possible solution: Close this duplicate branch and continue review or repair on #85478, keeping the classifier narrow to ripgrep no-match semantics. Do we have a high-confidence way to reproduce the issue? Yes for the patch defect: source inspection shows Is this the best way to solve the issue? No, this branch is not the best path because the canonical open PR tracks the same Slack behavior with supplied proof and a narrower ripgrep-specific classifier. The maintainable path is to review or repair the canonical PR rather than keep two competing branches open. Security review: Security review cleared: No concrete security or supply-chain regression was found; the issue is functional misclassification of command progress, not new command execution, dependency, CI, or secret handling. What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 7bc4a333aa09. |
|
ClawSweeper applied the proposed close for this PR.
|
Implements U1 + U2 + U3 for #85478 (canonical).
Narrow ripgrep-only classifier:
benign_no_resultbenign_no_resultsuccessorfailureU1:
src/agents/bash-tools.exec-outcome-classification.ts— pure classifier, no side effectsU2: Wired through
pi-embedded-subscribe.handlers.tools.ts→ agent events → reply pipelineU3: Slack progress renders
benign_no_resultasNo matches foundinstead of exit codeTests: 8 classification tests + 40 Slack dispatch tests + 22 channel-streaming tests + 113 agent-runner-execution tests
Closes #85478 (supersedes our closed duplicate PR)