Repository navigation
A memory that cannot be embedded or extracted blocks every memory after it #1187
Description
What happens
Every sentence said to remember goes into one document per base, memory-log.md, one chunk per sentence. When one of those chunks cannot be processed, every memory recorded after it is stuck too. The tool keeps answering "Recorded the sentence … the extracted facts await your confirmation", and no confirmation ever appears.
Reproduced on dev (bb5cde2)
A fresh base, a working chat and embedding model, remember called over MCP:
| Step | Pending facts for that sentence | Jobs |
|---|---|---|
| A. remember one sentence | 1 | memory_ingest done, extract_document done |
| B. remember a very long text (about 600,000 characters) | 0 | memory_ingest failed: Embedding request failed (400 Bad Request) |
| C. remember one sentence | 0 | memory_ingest failed, same error; no extract_document queued |
| D. remember one sentence | 0 | memory_ingest failed, same error |
After D the log holds three chunks with extracted_at empty, and it stays that way. The Library shows memory-log.md as ready and extracted: the failure is visible only in the jobs table.
A failure that goes away does not do this. With the chat key made invalid for one remember and then restored, the next remember extracted both sentences. A failed extraction of some other uploaded document does not affect memories either.
Why
pipeline::memory_ingestembeds every chunk of the log that has no vector, together, and stops at the first error. The chunk from B is in that set every time, so the job fails before it rebuilds the index or queues extraction. Nothing limits how long a remembered text may be.extraction_open::run_openreturns the "could not be extracted" error before its follow-up work. A chunk that fails extraction every time (read in the code, not reproduced here) would let later sentences reachpending_facts, butemit_pendingis skipped, so the chat's confirmation card is never told, andresolve_timeis not queued. The job is then retried and fails again.
What to change
rememberrefuses a text beyond a stated length and says so, instead of recording something the pipeline cannot read.- In
memory_ingest, a chunk that cannot be embedded does not stop the others: they get their vectors, the index is rebuilt and extraction is queued. - In
run_open, what was extracted gets its follow-up work (the pending notice, time resolution) before the incomplete attempt is reported.
Open after that: a memory that fails every time is retried with each new remember and keeps the log marked failed; there is no way yet to drop one sentence from the log.
Activity
WaylandYang commentedon Oct 10, 2026
Narrowed down after a second reproduction. The case that matters most is simpler than the long text above: while the embedding model answers with an error, no memory is extracted at all, though the chat model works. With an embedding key that is refused, two sentences were recorded and neither produced a pending statement (
memory_ingestfailed withEmbedding request failed (401)each time, and extraction is queued only after embedding). Both appeared once the key was restored and a third sentence was recorded.#1188 fixes the two causes. It does not add a length limit to
remember; that was dropped from the fix.WaylandYang commentedon Oct 11, 2026
Fixed on
devby #1188: an embedding error no longer stops a memory from being extracted, and a sentence that cannot be extracted no longer holds back the confirmation of the ones after it.