写入失败被上报为成功:cascade worker 不可恢复时 flush 仍返回 extracted;且失败无重试上限
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- python
- Ambito
- backend, backend-api-design
Direzione di ricerca
Start by tracing the POST /api/v1/memory/flush and POST /api/v1/memory/add entry points to the cascade worker, then read the existing tests for flush results and worker retries. The issue describes two related but independent failures and suggests possible approaches rather than specifying one implementation. Done means failed writes are not reported as extracted, and unrecoverable entries stop retrying after a bounded policy; add tests for both behaviors.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
一句话
cascade worker 处于持续失败状态时,写入 API 仍然返回成功 —— POST /api/v1/memory/add 返回 200、POST /api/v1/memory/flush 返回 {"status": "extracted"},而实际没有任何内容落库。宿主应用无法从 API 契约上察觉记忆已经停止工作。同时,失败条目没有重试上限,单次运行可产生数百条完全相同的不可恢复日志。
这是从 #337 排查中分离出来的两个独立问题。#337 的具体成因(subject_vector schema 漂移)已由 #354 检测 + 恢复,但下面两点不随之解决。
1. 写入失败被上报为成功
复现
在一个 episode 写入必然失败的库上(例如 #337 的 schema 漂移状态):
curl -X POST localhost:1995/api/v1/memory/add -H 'Content-Type: application/json' \
-d '{"user_id":"default","app_id":"default","session_id":"probe",
"messages":[{"role":"user","sender_id":"default","timestamp":1769500000000,"content":"probe"},
{"role":"assistant","sender_id":"agent","timestamp":1769500000001,"content":"ack"}]}'
# -> 200 {"data":{"message_count":2,"status":"accumulated"}}
curl -X POST localhost:1995/api/v1/memory/flush -H 'Content-Type: application/json' \
-d '{"user_id":"default","session_id":"probe"}'
# -> 200 {"data":{"status":"extracted"}}
同时服务端日志里是:
cascade_worker_unrecoverable kind=episode ...
RuntimeError: lance error: LanceError(IO): Execution error: Spill has sent an error
随后检索写入的内容,搜不到;episode 表行数不变。
影响
"status": "extracted" 在语义上表示抽取已完成,调用方据此认为写入成功。实际情况是这条记忆永久不会进入索引。
在我们的场景里,这导致 episode 写入静默失败了 18 天(表停在 7-09,期间零写入)才被发现 —— 因为:
- 写入侧 API 一直返回成功;
- recall 仍能召回旧数据(其他 kind 如
atomic_fact/foresight写入正常),看起来"记忆还活着"; - 宿主(Raven)的记忆后端是 fail-open 的:捕获异常后返回空结果,不向上抛,所以它自己的链路追踪里这些节点也全是绿的。
三者叠加,故障完全不可见。
为什么 #354 不覆盖
#354 的处理方式是启动期拒绝启动(检测到 schema 漂移就抛错),对这一类成因有效。但只要写入失败源于其他原因(嵌入服务异常、磁盘、下游超时等),cascade worker 依旧会静默失败,而 API 依旧返回 extracted。
建议
flush的返回值反映真实结果,例如在有条目进入failed/ 不可恢复状态时返回partial/degraded,并带上失败计数;- 或提供一个可查询的健康/降级状态(例如
/health中包含 cascade 队列的 failed 数量),让宿主能够主动探测; - 至少:当队列中存在不可恢复条目时,不要在响应中使用
extracted这种表示成功的措辞。
2. 不可恢复失败没有重试上限
同一批 md 条目在单次运行中产生了 330 条 cascade_worker_unrecoverable kind=episode,内容完全相同。这些重试没有任何成功可能(schema 漂移是确定性失败),只会持续消耗 CPU、写入日志噪声,并淹没其他有用日志。
建议
对同一条目引入重试上限或退避:达到上限后标记为终态 failed(附原因)并停止重排,让 cascade fix / cascade rebuild 去处理,而不是无限循环。
环境
- everos 1.1.3(1.2.0.dev1 表现相同)
- lancedb 0.33.0 / 0.34.0,pyarrow 25.0.0
- Python 3.12.13,macOS 26.3 arm64
- 宿主:Raven(通过
everos-memory插件走 HTTP 接入)
相关
- #337 —— 具体成因(episode
subject_vectorschema 漂移) - #354 —— schema 漂移检测 +
cascade rebuild恢复
- Lingua principale
- Python
- Stelle
- 13.3k
- Fork
- 926
- Merge medio
- 22h 56m
- PR unite (30g)
- 27
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di EverMind-AI/EverOS
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 62/100
EverMind-AI/EverOS#414 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
EverMind-AI/EverOS#537 ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: 同一 EverOS 账号下,不同 AI 客户端的记忆无法共享(user 隔离问题) / Cannot share memory between two AI clients under the same EverOS account (user isolation)Forse già presa @dani1005 l’ha presa 6 giorni fa. Apertabug
Difficoltà 4/5 1-2 giorni Idoneità per principianti 48/100
EverMind-AI/EverOS#528 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
memorize(): make delivery resumable per memcell so retries and replays are idempotentForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
EverMind-AI/EverOS#516 ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: add/flush returns 500 every time when an extraction reply quotes code with an unmatched `}` (everalgo brace-counting JSON extractor)Forse già presa @Kendrick-Song l’ha presa 8 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
EverMind-AI/EverOS#515 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di EverMind-AI/EverOS
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
MIT-LCP/wfdb-python#590 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
pollen-robotics/reachy_mini#1517 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 69/100
NRLMMD-GEOIPS/pluginify#41 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
scverse/spatialdata#1293 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
UKGovernmentBEIS/inspect_evals#2788 ·
I maintainer di solito rispondono entro 1 giorno