From 4227fe4f58f9c12cb012591bb2d98e693716d8ff Mon Sep 17 00:00:00 2001 From: NuklearRabbit <145918611+NuklearRabbit@users.noreply.github.com> Date: Wed, 5 Aug 2026 04:01:16 +0200 Subject: [PATCH] docs: record live /v1/answers verification and a retrieval finding Issued a fresh scoped credential via the RAGcore admin UI (separate, working OIDC session, unaffected by the n8n auth problem) and made a real authenticated /v1/answers call. Got a clean 200 with a real answer_id/retrieval_run_id, not degraded -- but not_answerable, 0 citations. Confirmed this isn't a regression: the same query through RAGcore's own pre-existing Query Lab tool (untouched this session) returns the identical result down to zero dense/sparse candidates at the raw retrieval stage. Ruled out the obvious causes via direct Qdrant/ Postgres checks -- workspace_id, space_id, status, and embedding digest all correctly match real indexed content. Root cause not yet found; flagged as a follow-up rather than pursued further to avoid scope creep on what was a deployment-verification task. Co-Authored-By: Claude Sonnet 5 --- PROJECT_STATE.md | 52 +++++++++++++++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 16 deletions(-) diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index aaf3cbf..bfc253d 100644 --- a/PROJECT_STATE.md +++ b/PROJECT_STATE.md @@ -1541,19 +1541,36 @@ Handler — both net-new, not yet built. - **Live-verified the fix itself**: `POST /v1/search` now returns `401 AUTHENTICATION_REQUIRED` for an unauthenticated call, not the old permanent `503 SEARCH_UNAVAILABLE` — proof the endpoint reaches real request handling instead of - hitting an absent application state, which is exactly the bug this closes. Did **not** - complete a full authenticated `/v1/answers` call with a real grounded-answer response - — the previously-issued "Fleet Ops Knowledge Assistant (production)" credential's raw - token was never persisted anywhere retrievable (tokens are shown once at issuance, - stored hashed thereafter) and issuing a fresh one requires the RAGcore admin control - API's own principal/session, not attempted this round to avoid another live-login - detour after the n8n incident above. Next session (or the user) should issue a fresh - scoped credential via the RAGcore admin UI and do one real `/v1/answers` call before - flipping `KNOWLEDGE_PROVIDER=ragcore`. + hitting an absent application state, which is exactly the bug this closes. + - **Issued a fresh scoped credential** (`answer` scope, application `Fleet Ops`, via the + RAGcore admin UI at `rag.itworx.tech` — a separate, working OIDC session, unaffected by + the n8n auth problem above) and made a real authenticated `POST /v1/answers` call + against the `Fleet Ops Procedures` knowledge space (`f4c91e49-5cf9-48ba-b3d6-e0e9854ebccc`). + Got a clean `200`, a real `answer_id`/`retrieval_run_id`, `degraded: false` — but + `answerability: not_answerable`, 0 citations, for two different real questions matching + real seeded document titles. + - **Confirmed this is not a regression from this change**: the same query against the + same space through RAGcore's own pre-existing, already-proven Query Lab tool (which + uses `PipelineQueryLabExecutor`, code this session never touched) returns the identical + `NOT_ANSWERABLE` / 0 evidence / not degraded result — down to `Dense candidates (0)` and + `Sparse candidates (0)` at the raw retrieval stage, before fusion or rerank ever runs. + Whatever is causing zero matches lives in shared retrieval infrastructure or the data + itself, not in the new production executors. + - **Ruled out the obvious causes via direct Qdrant/Postgres checks** (not yet root-caused + further — flagging as a separate follow-up, not blocking this task): the space + genuinely has 83 published, correctly-scoped points in `rag_dense_nomic-embed-text_v1` + (right `workspace_id`, right `space_id`, `status: published`, real Dutch-language + procedure text); the points' `embedding_model_digest` exactly matches the currently + active embedding profile's digest (no stale-embedding mismatch); the collection alias + (`rag_dense_nomic-embed-text_active`) correctly resolves to that same collection. One + oddity noted in passing, unrelated to retrieval: at least one sampled chunk has + `language: "en"` in its payload despite the actual text being Dutch — worth a look if + language-filtered queries matter for the demo. - **Decision on `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops**: still deliberately `demo`. - RAGcore's application is now deployed and structurally verified, but a full - authenticated grounded-answer call hasn't been done yet (see above) — flip only after - that final live check. + The application is deployed, correctly wired, and behaves identically to RAGcore's own + trusted reference implementation — but real questions against real seeded content + aren't returning grounded answers yet for a reason that traces to shared + retrieval/data, not to this wiring. Flip only after that's root-caused. - **n8n workflow 3 (task #86) — incident, recovered; final 2 nodes still blocked on a live n8n auth problem, not a code problem.** Returning to finish the "Summarize sync @@ -1591,10 +1608,13 @@ Handler — both net-new, not yet built. blocked before any node configuration happened. The design itself (mirroring WF2/WF4's existing report-result pattern) is unchanged from earlier planning. -- **Exact next action**: (1) RAGcore search/answer wiring (`a2905cc`) is now deployed and - structurally verified — issue a fresh scoped credential via the RAGcore admin UI, do one - real authenticated `/v1/answers` call, and only then reconsider flipping - `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops. (2) task #86's remaining n8n pieces (Summarize +- **Exact next action**: (1) RAGcore search/answer wiring (`a2905cc`) is deployed and + proven correctly wired (matches Query Lab's trusted behavior exactly) — the open item is + now root-causing why `Fleet Ops Procedures` returns zero dense/sparse candidates for + real questions despite having genuinely matching, correctly-scoped, correctly-embedded + indexed content (see evidence above); this is retrieval/data, not application wiring. + Only flip `KNOWLEDGE_PROVIDER=ragcore` once that's fixed and a real grounded answer comes + back. (2) task #86's remaining n8n pieces (Summarize + report-result node, publish) need the live n8n instance's save/auth problem fixed first — this looks like an n8n-instance-side issue (session/auth backend rejecting mutating requests moments after a successful login), not something fixable from the