Skip to content

Conversation

abrookins
Copy link
Collaborator

@abrookins abrookins commented Jul 31, 2025

Fixes issue #31 where hash-based deduplication reported finding N groups but merged 0 memories, causing confusing logs.

Also removes deprecated window_size parameter. Summarization is now based on token count, so you need to specify a model name (from which the server derives a max token count) or manually specify a max token count in order for us to auto-summarize messages in working memory.

Root Cause:

  • FT.AGGREGATE query was executed as a single string via execute_command()
  • This bypassed the FILTER "@count>1" clause, returning all groups including unique memories (count=1)
  • Processing logic correctly skipped count<=1 groups, resulting in 0 merges

Solution:

  • Change FT.AGGREGATE execution from single string to individual arguments
  • Use execute_command(*agg_query) instead of execute_command(agg_query)
  • This ensures the FILTER clause properly excludes unique memories
  • Added clearer logging messages

Testing:

  • All existing tests pass
  • Verified fix with integration test showing:
    • 5 memories (2 duplicates + 3 unique) → 4 memories (1 duplicate removed)
    • Proper logging: "Found 1 groups with hash-based duplicates to process"
    • Correctly removes duplicate while preserving unique memories

🤖 Generated with Claude Code

@Copilot Copilot AI review requested due to automatic review settings July 31, 2025 18:11
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes a bug in hash-based deduplication where the FT.AGGREGATE query was incorrectly executed as a single string, bypassing the FILTER clause and leading to confusing logs about finding N groups but merging 0 memories.

  • Changed FT.AGGREGATE execution from string to individual arguments to ensure proper filter clause processing
  • Improved logging messages for clarity and accuracy
  • Added logging for the case when no duplicates are found

Fixes issue #31 where hash-based deduplication reported finding N groups
but merged 0 memories, causing confusing logs.

**Root Cause:**
- FT.AGGREGATE query was executed as a single string via execute_command()
- This bypassed the FILTER "@count>1" clause, returning all groups including
  unique memories (count=1)
- Processing logic correctly skipped count<=1 groups, resulting in 0 merges

**Solution:**
- Change FT.AGGREGATE execution from single string to individual arguments
- Use execute_command(*agg_query) instead of execute_command(agg_query)
- This ensures the FILTER clause properly excludes unique memories
- Added clearer logging messages

**Testing:**
- All existing tests pass
- Verified fix with integration test showing:
  - 5 memories (2 duplicates + 3 unique) → 4 memories (1 duplicate removed)
  - Proper logging: "Found 1 groups with hash-based duplicates to process"
  - Correctly removes duplicate while preserving unique memories

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <[email protected]>
@abrookins abrookins force-pushed the fix/hash-deduplication-issue-31 branch from c7ed894 to ac6d88b Compare July 31, 2025 19:10
…tion work

The test was expecting summarization to trigger but the messages were under
the 1000 token limit. Increased the message length to ensure summarization
happens and made the token count assertion more flexible since it varies
based on actual content.
- Replace window_size parameter with model_name in examples and test files
- Rename effective_window_size to effective_token_limit in API for clarity
- Update all references to use the current token-based API instead of
  the old message-count based window_size approach
1. Fix string consistency in FT.AGGREGATE query parameters - now all
   numeric parameters are explicitly converted to strings using str()

2. Handle tool messages and other unknown roles in memory_prompt API -
   treat non-user/assistant roles as assistant messages for MCP compatibility
   since MCP base only supports UserMessage and AssistantMessage types
@abrookins abrookins merged commit 2b623b1 into main Jul 31, 2025
10 checks passed
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