Skip to content

[Bug]: fact_store list action always returns empty due to SQL parameter ordering bug #28055

@back1024

Description

@back1024

Bug Description

fact_store(action='list') always returns {"facts": [], "count": 0} regardless of parameters (category, min_trust, limit, offset, sort_by). Meanwhile search, probe, and other actions work correctly.

Steps to Reproduce

  1. Add a fact: fact_store(action='add', content='test fact')
  2. Call fact_store(action='list') → returns {"facts": [], "count": 0}
  3. But fact_store(action='search', query='test') correctly returns the fact

Expected Behavior

fact_store(action='list') should return all stored facts with pagination support, respecting category filter and min_trust threshold.

Actual Behavior

Always returns {"facts": [], "count": 0} regardless of parameters.

Affected Component

Agent Core (conversation loop, context compression, memory)

Messaging Platform (if gateway-related)

No response

Debug Report

hermes doctor output: Hermes Agent v0.13.0 (Tenacity Release, 2026.5.7), Python 3.11.15, macOS 26.4.1

Operating System

macOS 26.4.1

Python Version

3.11.15

Hermes Version

v0.13.0

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

In plugins/memory/holographic/store.py line 358, the list_facts method builds SQL with LIMIT ? OFFSET ? but binds parameters in reverse order:

params.extend([offset, limit])

The SQL:

LIMIT ? OFFSET ?

SQLite positional binding means ? is bound in array order: offset (0 by default) → LIMIT, limitOFFSET. Since offset defaults to 0, LIMIT always receives 0, returning zero rows.

This affects ONLY list_facts because other methods (search, probe) use different SQL builders in FactRetriever that don't have this bug.

Proposed Fix (optional)

Line 358 of plugins/memory/holographic/store.py:

- params.extend([offset, limit])
+ params.extend([limit, offset])

Also, the category parameter enum in FACT_STORE_SCHEMA (line 66 of __init__.py) only lists ["user_pref", "project", "tool", "general"], but the codebase uses legal_index and case_deep extensively. Consider adding them to the enum to avoid issues with strict function-calling providers.

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havecomp/pluginsPlugin system and bundled pluginstool/memoryMemory tool and memory providerstype/bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions