Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix memory-lancedb: stale recall can answer 'latest' queries without recency/provenance [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59130•Fetched 2026-04-08 02:28:20
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
slip17mcslip17mc
Participants
slip17mcslip17mc
Timeline (top)
cross-referenced ×1

memory-lancedb can answer "latest / most recent" questions from stale recalled memories because recall is pure semantic similarity with no recency-aware ranking/filtering and no assistant-visible provenance telling the user whether the answer came from recalled memory vs a live source query.

Root Cause

Summary

memory-lancedb can answer "latest / most recent" questions from stale recalled memories because recall is pure semantic similarity with no recency-aware ranking/filtering and no assistant-visible provenance telling the user whether the answer came from recalled memory vs a live source query.

Fix Action

Fixed

PR fix notes

PR #59141: fix(memory-lancedb): prefer newer memories for latest queries

Description (problem / solution / changelog)

Summary

  • detect freshness-sensitive prompts in memory-lancedb (latest/last/most recent/newest/current/recent)
  • widen candidate recall and rerank recalled memories using recency + semantic similarity
  • surface timestamp/provenance hints in freshness-sensitive recalled memory context
  • add regression coverage for stale-vs-newer recall ordering

Why

Fixes cases where memory recall answered a "latest" question from an older remembered item instead of the newer matching memory.

Fixes #59130

Changes

  • add freshness intent detection
  • rerank freshness-sensitive recall results using createdAt
  • include recordedAt timestamps and a freshness note in recalled context
  • expose timestamp data in recall/search output
  • add tests for freshness detection, recall ordering, and non-freshness fallback ordering

Testing

  • pnpm exec vitest run --config vitest.extensions.config.ts extensions/memory-lancedb/index.test.ts

Notes

This is a minimal safety fix using memory createdAt. A stronger follow-up would add structured source provenance and source timestamps.

Changed files

  • extensions/memory-lancedb/index.test.ts (modified, +282/-1)
  • extensions/memory-lancedb/index.ts (modified, +207/-53)
RAW_BUFFERClick to expand / collapse

Summary

memory-lancedb can answer "latest / most recent" questions from stale recalled memories because recall is pure semantic similarity with no recency-aware ranking/filtering and no assistant-visible provenance telling the user whether the answer came from recalled memory vs a live source query.

Real-world failure

In a Telegram workflow, a newer YouTube link was sent to an inbox topic, but the assistant answered with an older captured video. The answer came from previously injected <relevant-memories> context instead of the newest inbox item.

That makes the system feel like it is "querying the inbox" when it is actually answering from stale memory context.

Current behavior

extensions/memory-lancedb/index.ts currently:

  • embeds the raw prompt in before_agent_start
  • runs db.search(vector, 3, 0.3)
  • prepends the top semantic matches as <relevant-memories>

The DB schema is also minimal:

  • text
  • vector
  • importance
  • category
  • createdAt

There is no first-class source metadata, source-type metadata, source timestamp, channel/thread provenance, or recency-aware ranking path for prompts that imply freshness (latest, last, most recent, newest, current, etc.).

Why this is a problem

  1. Freshness-sensitive queries are unreliable
    Semantic similarity alone is not enough for "latest" asks.
  2. Users cannot tell where the answer came from
    The assistant may sound definitive even when it is only using recalled context.
  3. Memory recall and live source access are conflated
    The system needs a clearer boundary between recalled memory and real-time source lookup.

Expected behavior

For prompts that imply recency/freshness:

  • either prefer the newest matching memory entries by timestamp / source timestamp,
  • or explicitly say the answer is from recalled memory and may be stale,
  • or route to a live/history query path when available.

At minimum, the user should be able to tell whether the answer came from:

  • recalled memory (relevant-memories / LanceDB), or
  • a live source/history query.

Proposed fixes

Option A — Recency-aware memory ranking

Add recency-aware retrieval for freshness-intent prompts:

  • detect freshness intent from the prompt (latest, last, most recent, newest, current, etc.)
  • rank or filter candidate memories by timestamp in addition to semantic score
  • support source timestamps when available, not only ingest createdAt

Option B — Structured memory metadata

Extend memory entries to support structured provenance fields like:

  • sourceType
  • sourceId
  • sourceUrl
  • sourceChannel
  • sourceThread/topic
  • sourceTimestamp
  • capturedAt

Option C — Assistant-visible provenance/debug receipt

Add an assistant-visible or opt-in debug/provenance mode so the assistant can say things like:

  • "This answer is based on recalled memory from LanceDB, not a live inbox query."
  • "Source timestamp: ..."

Option D — Better fallback behavior

If the system cannot verify freshness, it should prefer a cautious answer over a confident stale answer.

Acceptance criteria

  • A freshness-sensitive prompt no longer returns an older memory when a newer matching memory exists.
  • The recall path can use timestamp metadata in ranking/filtering.
  • There is a clear way to surface provenance or stale-memory caveats to the assistant/user.
  • Add regression tests covering a "latest item" prompt where semantic similarity alone would otherwise select the wrong older memory.

Relevant code

  • extensions/memory-lancedb/index.ts
    • before_agent_start auto-recall path
    • MemoryDB.search()
  • extensions/memory-lancedb/ingest.mjs
    • schema / ingest path

Notes

This is not only a UX issue. It changes user trust because the assistant can appear to be querying the latest inbox state while actually answering from stale injected memory context.

extent analysis

TL;DR

Implement recency-aware memory ranking by detecting freshness intent in prompts and ranking candidate memories by timestamp in addition to semantic score.

Guidance

  • Detect freshness intent in prompts by checking for keywords like "latest", "last", "most recent", "newest", "current", etc.
  • Modify the MemoryDB.search() function to rank or filter candidate memories by timestamp in addition to semantic score.
  • Consider adding source timestamps to memory entries to improve accuracy.
  • Implement a fallback behavior that prefers a cautious answer over a confident stale answer when freshness cannot be verified.

Example

// Example of modified MemoryDB.search() function
MemoryDB.search = (vector, limit, threshold, prompt) => {
  const freshnessIntent = detectFreshnessIntent(prompt);
  if (freshnessIntent) {
    // Rank candidate memories by timestamp and semantic score
    const results = db.query(`SELECT * FROM memories WHERE vector_similarity($1, vector) > $2 ORDER BY createdAt DESC`, [vector, threshold]);
    return results.slice(0, limit);
  } else {
    // Default behavior: rank by semantic score only
    const results = db.query(`SELECT * FROM memories WHERE vector_similarity($1, vector) > $2 ORDER BY similarity DESC`, [vector, threshold]);
    return results.slice(0, limit);
  }
};

Notes

The proposed fix requires modifications to the extensions/memory-lancedb/index.ts file, specifically the before_agent_start auto-recall path and the MemoryDB.search() function. Additionally, the schema and ingest path in extensions/memory-lancedb/ingest.mjs may need to be updated to support source timestamps.

Recommendation

Apply workaround by implementing recency-aware memory ranking, as it addresses the root cause of the issue and provides a clear solution to the problem. This approach ensures that freshness-sensitive queries return the most recent matching memories, improving the overall user experience and trust in the system.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

For prompts that imply recency/freshness:

  • either prefer the newest matching memory entries by timestamp / source timestamp,
  • or explicitly say the answer is from recalled memory and may be stale,
  • or route to a live/history query path when available.

At minimum, the user should be able to tell whether the answer came from:

  • recalled memory (relevant-memories / LanceDB), or
  • a live source/history query.
#model compatibility#GPU setup#container setup#orchestration issue#cache issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING