[Repo Assist] test(chat): add regression coverage for failed-tool + final-assistant sequence#692
Conversation
…ant sequence (#672) Add 5 new ChatTimelineReducer tests that pin the expected state for the sequence: ToolStart → ToolError → final ChatMessageEvent → ChatTurnEnd. This is regression coverage for issue #672 (Companion shows stale failed tool event while web UI shows completed response). The bug is in the rendering layer (OpenClawChatTimeline reorders ToolCall entries to appear after non-ToolCall entries within a turn, placing the error at visual bottom while the assistant reply scrolls off screen), but the reducer state is correct — these tests document and lock that. Tests added: - ToolError_ThenFinalAssistant_ProducesToolAndAssistantEntries - ToolError_ThenFinalAssistant_AssistantHasFinalText - ToolError_ThenFinalAssistant_TurnIsEnded - ToolError_ThenFinalAssistant_ToolEntryPrecedesAssistantInState - ToolError_ThenFinalAssistant_ToolOutputContainsErrorText Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Codex review: found issues before merge. Reviewed June 4, 2026, 9:52 PM ET / 01:52 UTC. Summary Reproducibility: yes. for the reducer baseline from source inspection: the ToolStart, ToolError, final ChatMessage, and TurnEnd path produces the state shape the PR tests. The actual Windows Companion visual bug remains represented by the linked issue rather than reproduced here in a live UI run. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Land this reducer baseline only if maintainers want a separate checkpoint, then fix the visible renderer ordering or scroll behavior in the linked issue with Windows Companion proof. Do we have a high-confidence way to reproduce the issue? Yes for the reducer baseline from source inspection: the ToolStart, ToolError, final ChatMessage, and TurnEnd path produces the state shape the PR tests. The actual Windows Companion visual bug remains represented by the linked issue rather than reproduced here in a live UI run. Is this the best way to solve the issue? Unclear as a complete fix: the tests are a reasonable baseline, but the visible bug lives in Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 99efc50cbc22. Label changesLabel changes:
Label justifications:
Evidence reviewedAcceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
🤖 This PR was created by Repo Assist, an automated AI assistant.
Summary
Adds 5 new
ChatTimelineReducerunit tests that pin the expected state for the sequence:Motivation
This is regression coverage for issue #672 (Windows Companion Chat shows stale failed tool event while web UI shows completed assistant response).
The bug is in the rendering layer —
OpenClawChatTimeline.csreorders entries within each turn so allToolCallentries appear after all non-ToolCallentries. For the failure case, this puts the failed tool event at the visual bottom (where auto-scroll lands), while the final assistant response is above it and off-screen.The reducer state is already correct — this PR locks that behavior with tests so any future fix can proceed with confidence.
Tests added (
ChatTimelineReducerTests.cs)ToolError_ThenFinalAssistant_ProducesToolAndAssistantEntriesToolError_ThenFinalAssistant_AssistantHasFinalTextToolError_ThenFinalAssistant_TurnIsEndedToolError_ThenFinalAssistant_ToolEntryPrecedesAssistantInStateToolError_ThenFinalAssistant_ToolOutputContainsErrorTextRelationship to issue #672
The
ToolEntryPrecedesAssistantInStatetest explicitly documents the state insertion order. This is the baseline for a future rendering fix: the rendering layer should keep the final assistant response as the last visible item after a failed tool.Test Status
dotnet test OpenClaw.Tray.Tests— 941 total, 939 passed, 2 skipped (infrastructure-related), 0 faileddotnet test OpenClaw.Shared.Tests— 8 pre-existing failures on master (unrelated to these changes), confirmed identical on both master and this branch./build.ps1— not run (Windows PowerShell build script, not available in Linux CI environment; this is an infrastructure limitation)