Memory - Fix: Update relation filter logic to use OR condition instead of AND

[dimalo]

Description

This PR updates the relation filtering logic in the memory server's searchNodes and openNodes methods to correctly include relations connected to at least one filtered entity.

Server Details

• Server: memory
• Changes to: searchNodes and openNodes tools

Motivation and Context

The current implementation filters relations using an && condition, meaning a relation is only included if both its source and destination entities are present in the filtered entity list. This is incorrect behavior as it excludes relations that connect a filtered entity to an unfiltered one. The expected behavior is to include any relation where either the source or destination entity is in the filtered list.

How Has This Been Tested?

• Manually tested with the openNodes tool to verify correct relation inclusion
• Verified that relations are now included when connected to at least one filtered entity

Breaking Changes

None. This is a bug fix that maintains backward compatibility.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

The change replaces the && condition with an || condition in both searchNodes and openNodes methods:

const filteredRelations = graph.relations.filter(r => 
  filteredEntityNames.has(r.from) || filteredEntityNames.has(r.to)
);

[undecidedapollo]

This PR fixed an issue I was having. I wanted it to find the children of a node and open_node would show no relationships so it reverted to read_graph instead. What steps are required to get this merged or is there a reason it is currently set to &&?

[domdomegg]

After reviewing this PR, I believe the original implementation with && is actually correct and this change should not be merged.

The current behavior intentionally filters relations to only show those between filtered entities, which creates a coherent subgraph view. This is the expected behavior when filtering a knowledge graph.

Consider this example:

• You search for "Python" and get entities A, B, and C
• Entity A has relations to both B (inside filtered set) and Z (outside filtered set)

graph LR
    A[Entity A - filtered] --> B[Entity B - filtered]
    A --> Z[Entity Z - not filtered]
    B --> C[Entity C - filtered]
    Z --> Y[Entity Y - not filtered]
    
    style A fill:#90EE90
    style B fill:#90EE90
    style C fill:#90EE90
    style Z fill:#FFB6C1
    style Y fill:#FFB6C1

Loading

With the current && logic, you get this clean subgraph:

graph LR
    A[Entity A] --> B[Entity B]
    B --> C[Entity C]

Loading

With the proposed || logic, you'd get dangling relations:

graph LR
    A[Entity A] --> B[Entity B]
    A -.-> Z:::missing
    B --> C[Entity C]
    
    Z[Entity Z - missing]:::missing
    
    classDef missing stroke-dasharray: 5 5, fill:#f96

Loading

The comment in the code accurately describes this: "Filter relations to only include those between filtered entities" - this means both endpoints must be in the filtered set, which is what users typically expect when viewing a filtered portion of a knowledge graph.