Follow-up to #204 (Knowledge Base AI index status).
Problem
GET /api/v1/ingest/status reads only the ingestion metadata store. If deindexing an artifact fails in the vector store, retrieval already stops using it, but its metadata record still says completed until the backend's retry succeeds and marks it deindexed.
During that window the route reports the artifact as indexed. The Knowledge Base chip then shows "Indexed" for a file the assistant no longer uses.
Why it was accepted for v1
- It is rare: it needs a failed deindex, and the backend retries.
- The chip's wording already avoids promising that the chatbot can answer from the file.
- Fixing it needs a decision on where the pending removals live.
Proposed fix (~0.5 d incl. tests)
- Check pending or failed removals when building the status, and report them as
deindexed (or a new removing state; that needs a backend and frontend enum change).
- Add a test for the failed-deindex window: the artifact must not report
indexed.
Counterparts: SprintStartProject/sprintstart-backend#258, SprintStartProject/sprintstart-frontend#264.
Follow-up to #204 (Knowledge Base AI index status).
Problem
GET /api/v1/ingest/statusreads only the ingestion metadata store. If deindexing an artifact fails in the vector store, retrieval already stops using it, but its metadata record still sayscompleteduntil the backend's retry succeeds and marks itdeindexed.During that window the route reports the artifact as
indexed. The Knowledge Base chip then shows "Indexed" for a file the assistant no longer uses.Why it was accepted for v1
Proposed fix (~0.5 d incl. tests)
deindexed(or a newremovingstate; that needs a backend and frontend enum change).indexed.Counterparts: SprintStartProject/sprintstart-backend#258, SprintStartProject/sprintstart-frontend#264.