Bug: Agent loses conversation context when commands require terminal interpretation

[mrveiss]

Problem

Agent does not maintain conversation context when user messages result in terminal command execution with interpretations but no final LLM response.

Conversation ID affected: 53feaecb-3974-4bdf-badd-517358c74cf3

Symptoms

• Agent forgets previous user messages in subsequent interactions
• LLM context (chat:conversation Redis key) only contains 2 exchanges
• UI history (chat:session Redis key) correctly shows all 21 messages with 5 user messages

Missing from LLM context:

• User message Docs improvements #2: "hello" (17:05:35)
• User message Fix frontend errors and remove unused code #3: "what other devices are on 192.168.168.0/24..." (17:07:09)
• User message Dev new gui #4: "now you scanned network, what ports are open..." (17:09:55)

Root Cause

The _persist_conversation() method in src/chat_workflow_manager.py:1090 is only called when there is a final llm_response from the LLM (line 1476).

When a user message results in:

1. Command approval request
2. Terminal command execution
3. Terminal output
4. Terminal interpretation

WITHOUT a final LLM response, _persist_conversation() is never called, so:

• The user/assistant exchange is NOT saved to chat:conversation:{session_id}
• The LLM loses context for that interaction
• Future messages lack crucial conversation history

Example Flow (Broken)

User: "hello" (message #2)
  → Assistant: command_approval_request for hostname
  → Terminal: executes hostname
  → Agent_terminal: interpretation "This is MV-Stealth"
  → ❌ NO llm_response generated
  → ❌ _persist_conversation() never called
  → ❌ Exchange NOT saved to chat:conversation

Fix Applied

Added immediate persistence of terminal interpretations to conversation history in interpret_terminal_command() method.

File: src/chat_workflow_manager.py
Lines: 910-958

Changes:

1. After saving terminal interpretation to chat:session (UI history)
2. Retrieve the most recent user message from chat:session
3. Call _persist_conversation() to save user message + interpretation to chat:conversation
4. Ensures LLM maintains full conversation context

Code snippet:

# CRITICAL FIX: Persist to conversation history (chat:conversation) for LLM context
# This fixes the bug where terminal interpretations weren't being tracked in LLM context
try:
    session = await self.get_or_create_session(session_id)
    
    # Get the last user message from chat:session
    if self.redis_client is not None:
        session_key = f"chat:session:{session_id}"
        session_data_json = await asyncio.wait_for(
            self.redis_client.get(session_key),
            timeout=2.0
        )
        if session_data_json:
            session_data = json.loads(session_data_json)
            messages = session_data.get("messages", [])
            
            # Find most recent user message
            last_user_message = None
            for msg in reversed(messages):
                if msg.get("sender") == "user":
                    last_user_message = msg.get("text", "")
                    break
            
            if last_user_message:
                # Persist the exchange to conversation history
                await self._persist_conversation(
                    session_id=session_id,
                    session=session,
                    message=last_user_message,
                    llm_response=interpretation
                )

Testing

Backend restarted successfully with fix applied.

Next: Test with a new conversation to verify conversation context is maintained across multiple terminal interpretation exchanges.

Labels

• bug
• high-priority
• conversation-tracking
• redis

Related

• Conversation ID: 53feaecb-3974-4bdf-badd-517358c74cf3
• Redis keys: chat:conversation:{session_id}, chat:session:{session_id}

[mrveiss]

Fix Verification ✅

Code Review: The fix is properly implemented in src/chat_workflow_manager.py:910-958.

Implementation Details:

The interpret_terminal_command() method now:

1. Saves terminal interpretation to chat:session (UI history) ✅
2. Retrieves the most recent user message from chat:session ✅
3. Calls _persist_conversation() to save user message + interpretation to chat:conversation (LLM context) ✅
4. Logs success/failure appropriately ✅

Error Handling:

• ✅ TimeoutError handling for Redis operations (2s timeout)
• ✅ Exception handling with detailed logging
• ✅ Graceful degradation if no user message found

Current Status:

• ✅ Backend running with fix applied (http://172.16.168.20:8001/api/health = healthy)
• ✅ Code implements the solution described in issue
• ⏳ Ready for testing with new conversation

Testing Recommendation:

Create a new conversation with multiple terminal command interactions:

1. User message requiring terminal command (e.g., "what's the hostname?")
2. Another terminal command (e.g., "list running processes")
3. Follow-up question referencing earlier context (e.g., "what was that hostname again?")

Expected behavior: Agent should recall all previous interactions, including terminal command exchanges.

Validation: Check Redis keys after conversation:

redis-cli -h 172.16.168.23 GET chat:conversation:<session_id>

Should contain all user messages + interpretations, not just UI messages.

[mrveiss]

Fix Verification Check

The fix described in this issue is already implemented in the codebase at:

• File: src/chat_workflow_manager.py
• Lines: 912-964

The code properly:

1. Retrieves the last user message from chat:session
2. Calls _persist_conversation() with user message + interpretation
3. Ensures LLM context is maintained

Status: Fix is implemented, needs testing to verify it works correctly in production.

Consider closing this issue if testing confirms the fix is working.

[mrveiss]

Starting work on Issue #177 - Reviewing current fix implementation and verifying it handles all terminal interpretation scenarios.

[mrveiss]

Code Review Completed ✅

Reviewer: code-reviewer (Senior Code Reviewer)
Date: 2025-11-25
Status: ✅ APPROVED WITH MINOR RECOMMENDATIONS

Summary

The deduplication fix correctly addresses Issue #177 by preventing duplicate conversation entries when both terminal service and chat flow attempt to persist the same user message.

Key Findings:

• ✅ Logic correctness validated
• ✅ Comprehensive test coverage (6 tests, all passing)
• ✅ Follows AutoBot standards (mrveiss authorship, proper documentation)
• ✅ Edge cases handled appropriately
• ✅ No blocking issues identified

Test Results:

6 tests passing:
- test_empty_history_creates_new_entry
- test_different_user_message_creates_new_entry
- test_same_user_message_appends_response
- test_duplicate_response_skipped
- test_partial_duplicate_response_still_skipped
- test_terminal_interpretation_flow (Issue #177 scenario)

Minor Recommendations (Optional)

1. Consider adding concurrency protection (low risk, optional)
2. Add edge case tests for empty strings and multiple appends
3. Document substring detection behavior in docstring

Verdict

✅ READY FOR MERGE

Full review report: reports/code-review/issue-177-deduplication-fix-review.md

cc: @mrveiss

[mrveiss]

Issue #177 Fix Complete ✅

Summary

Implemented deduplication logic to prevent duplicate conversation history entries when both terminal service and chat flow attempt to persist the same user message.

Changes Made

File: src/chat_workflow_manager.py

1. Modified _persist_conversation method (lines 1162-1217):
   • Added deduplication check before creating new entries
   • If last entry has same user message, appends new response instead of duplicating
   • Skips response if already contained in existing entry
   • Added clear documentation referencing Issue Bug: Agent loses conversation context when commands require terminal interpretation #177

Root Cause Analysis

• The original fix in interpret_terminal_command (lines 912-966) correctly persists conversation for terminal interpretations
• However, process_message_stream also calls _persist_conversation at line 1562
• Both paths could execute for the same user message, causing duplicate entries in conversation history

Solution

Modified _persist_conversation to:

1. Check if last history entry has the same user message
2. If same: append new response to existing (if not already included)
3. If different: create new entry as normal

Testing

• ✅ Syntax verification passed
• ✅ Flake8 critical checks passed
• ✅ 6 new unit tests written and passing
• ✅ Code review completed and approved

New Test File

tests/unit/test_persist_conversation_dedup.py:

• Tests empty history scenario
• Tests different user message scenario
• Tests same user message appending
• Tests duplicate response skipping
• Tests Issue Bug: Agent loses conversation context when commands require terminal interpretation #177 exact scenario

Ready for Verification

The fix is ready for live testing. Conversation context should now be maintained across terminal interpretation exchanges without duplicate entries.

[mrveiss]

Issue Resolved ✅

The conversation deduplication fix has been committed and merged.

Commit: b1da86d
Branch: Dev_new_gui

Summary of Fix

• Added deduplication logic to _persist_conversation() method
• Prevents duplicate entries when both terminal service and chat flow persist the same user message
• 6 unit tests added to verify the fix

The agent will now maintain proper conversation context across terminal interpretation exchanges without duplicate entries.