[OMEGA-352] Bug 18 Memory Retrieval via query() Does Not Function

[olegryabchikov-dot]

Describe the bug

The memory retrieval mechanism (query) does not return data stored via remember(). When a user asks the bot to recall previously stored information by key, query() enters an indefinite no_action loop and never returns a result. Additionally, remember() is called before tool data is available, storing placeholder text instead of actual values. While self-correction overwrites the placeholder with correct data, this ordering issue is currently irrelevant because retrieval fails regardless of stored data correctness.

To Reproduce

Steps to reproduce the behavior:

1.  Send 'Find the current Bitcoin price via websearch and remember the result via remember with key "btc-price". Then show me what you remembered.' to agent
   

2.  Wait for confirmation response (~1 minute)
   

3.  Send 'What exactly is stored in memory under key btc-price? Show the exact contents via query-memory.' to agent
   

4.  Wait indefinitely — no response is received
   

Expected behavior

query("btc-price") should return the value previously stored by remember("btc-price", ...). The bot should display the stored price data to the user.

Actual behavior

1.  First remember() call stores placeholder text "CURRENT_BTC_PRICE_PLACEHOLDER" because it executes simultaneously with websearch before data is available
   

2.  Second remember() call ~40 seconds later correctly stores real price data (self-correction)
   

3.  query("btc-price") enters indefinite no_action loop: "still waiting for query result for btc-price key"
   

4.  After 4+ minutes with no result, bot acknowledges hang: "The query command for key btc-price is still waiting for a result"
   

5.  Retry of query("btc-price") also hangs indefinitely
   

6.  Filesystem inspection confirms no separate key-value store exists; remember() only writes log entries to history.metta; workflow_space directory is empty
   

Additional context

· OmegaClaw version: v0.1.18
· Communication channel: Telegram
· Model provider: M3
· Primary actionable bug: query() failure — memory retrieval does not function
· Secondary observation: Premature remember() with placeholder text is a reasoning/ordering issue, but has no functional impact given that retrieval fails independently of stored data correctness
· Self-correction mechanism observed: model issues second remember() with correct data after tool completes, partially mitigating the ordering issue
· Memory architecture appears to be write-only log (history.metta) without functional key-value retrieval

[paul-v-snet]

Hi @olegryabchikov-dot!

Could you please share the values from your environment configuration (related to Omega directly, excluding sensitive data), especially everything you configured manually if you changed anything from the defaults? If not, the log should be sufficient (see the text above the attachment).

I've tried to reproduce the issue you described, but everything works well for both OpenAI and M3 providers. So I guess the reason for the issue may be related to the launch parameters or other configured values.

My environment and Omega specs:

• OmegaClaw version: v0.1.18
• Communication channel: Telegram/IRC
• Model provider: M3/OpenAI
• Any other params are configured by default

Below, I'm providing logs where we can see that the issue cannot be reproduced:

---

loop | (HUMAN-MSG: @...: Find the current Bitcoin price via websearch and remember the result via remember with key quote_btc-price_quote. Then show me what you remembered.)

loop | (RESPONSE: ((websearch "current Bitcoin price USD")))

loop | (RESPONSE: (RESULTS: ((COMMAND_RETURN: ((websearch "current Bitcoin price USD") ((TITLE: Bitcoin price today, BTC to USD live price...

loop | (RESPONSE: ((remember "btc-price: ~$63,353 USD (CoinMarketCap live, 24h volume $23.15B, mcap $1.27T, down 0.31% 24h)") (send "Remembered BTC price: ~$63,353 USD (per CoinMarketCap live feed).")))

• Additionally, remember() is called before tool data is available, storing placeholder text instead of actual values - that's not happened

loop | (RESPONSE: (RESULTS: ((COMMAND_RETURN: ((remember "btc-price: ~$63,353 USD (CoinMarketCap live, 24h volume $23.15B, mcap $1.27T, down 0.31% 24h)") REMEMBER-SUCCESS)) (COMMAND_RETURN: ((send "Remembered BTC price: ~$63,353 USD (per CoinMarketCap live feed).") None)))))

loop | (HUMAN-MSG: @...: What exactly is stored in memory under key btc-price? Show the exact contents via query-memory.)

loop | (RESPONSE: ((query "btc-price")))

loop | (RESPONSE: (RESULTS: ((COMMAND_RETURN: ((query "btc-price") [['2026-08-13 11:12:02', 'btc-price: ~$63,353 USD (CoinMarketCap live, 24h volume $23.15B, mcap $1.27T, down 0.31% 24h)']])))))

loop | (RESPONSE: ((send "Queried memory for "btc-price": btc-price: ~$63,353 USD (CoinMarketCap live, 24h volume $23.15B, mcap $1.27T, down 0.31% 24h)")))

---

I tried several times but it worked fine every time - maybe I'm missing something?

---

I'm also attaching the full log.
Could you please reproduce the issue again, capture the log, and provide it to me, similar to the one I provided below?

issue_311.log

[olegryabchikov-dot]

Hi @paul-v-snet!
Follow-up with full reproduction logs as requested. I ran the exact OMEGA-352 test case on a fresh v0.1.18 + M3 + Telegram deployment (clean volume, no prior history).
Result: NOT REPRODUCED on fresh container
Both remember and query-memory worked correctly:
Prompt 1: Find the current Ethereum price via websearch and remember the result via remember with key "eth-price". Then show me what you remembered.
Bot response: Remembered. Key: eth-price = ~$1,887 USD. Sources: Coinbase $1,888.73 / CoinDesk $1,885.53 (Aug 12 2026).
Prompt 2: What exactly is stored in memory under key eth-price? Show the exact contents via query-memory.
Bot response: eth-price = ~$1,887 USD (ETH, Aug 12 2026 per CoinDesk; sources cluster $1,885–$1,888)
Framework log evidence (docker logs)
Key events confirming successful execution:

12345678910111213
No hang. No no_action loop. COMMAND_RETURN delivered successfully with structured data.
History growth during test
Before: 1039 lines
After: 1184 lines (+145 lines)
Observation: early async degradation symptom
While query-memory worked fine, websearch required multiple retry attempts even on this fresh container (~20 tool calls total):
09:20:14 — 1st websearch call
09:20:27 — 2nd call (retry after 13s)
09:21:45 — 3rd call (retry after ~78s of idle-wait)
09:22:44 — 4th call (retry)
09:23:04 — 5th call (modified query, finally succeeded at 09:23:20)
This suggests async tools may begin degrading early, even before the full death observed in Session 1. The query-memory bug from OMEGA-352 may be a late-stage symptom that only manifests after significant async tool degradation has accumulated.
Hypothesis for further testing
OMEGA-352 may require extended session state to trigger. I will continue load testing this fresh container to see if query-memory eventually enters the no_action loop as async tools degrade further. Will report back if/when reproduction succeeds.

[Sunster1970]

Corroborating the maintainer's non-repro: on our deployment (chromadb persistent store, local e5-large-v2 embeddings) the remember() → query() path works correctly — stored content returns as [[time, content]] as in the maintainer's log.

Two adjacent failure modes we did measure, which produce the same operator-visible symptom (agent queries, then no_action-loops, user concludes memory is broken):

1. Single-cycle result visibility — the query result reaches context for one cycle; if the model doesn't act immediately, the next cycle's empty results overwrite it (details in my comment on Bug 20: Tool Result Delivery Failure in Chain/Stress Context #314). The model then has nothing to answer from, and at low temperature it tends to idle rather than re-query.
2. Answer-suppression at low temperature — with strict "send only when triggered" prompt rules, the model retrieves the correct memory and still declines to send, narrating instead (or idling). Explicitly instructing usage ("use your query skill, then use your send skill to tell me…") broke the deadlock in our case, after which the healthy example in history made plain questions work.

Neither is a chromadb defect. Suggest the reporter check (a) whether the query result appears in the loop's result feedback at all (if yes, it's visibility/behavior, not storage), and (b) cold-start latency of the embedding model on first use, which can look like a hang.

[paul-v-snet]

We're closing this issue due to the issue being unreproducible.