Parent Epic: #162
Depends on: #163
Goal
Add an optional LightRAG REST client behind the retrieval contracts from Step 1. Validate API behavior, configuration, response normalization, and failure handling without changing the production retrieval backend.
Deployment Boundary
LightRAG runs as an independent service. CacheRoute components communicate through a small asynchronous REST adapter. Do not import or initialize LightRAG Core inside Scheduler, KDN, Proxy, or Instance processes in this step.
Scope
- Implement an async
LightRAGClient with connection reuse and explicit timeouts.
- Support health/readiness checks.
- Support document indexing, query-data/context retrieval, document deletion, and status/error normalization needed by later steps.
- Implement
LightRAGKnowledgeRetriever that converts LightRAG responses into backend-neutral RetrievalResult objects.
- Use retrieval-only outputs. Do not request or consume LightRAG's final generated answer in the CacheRoute online path.
- Support at least
naive and mix query modes through configuration.
- Validate response shape, bound metadata, reject malformed or oversized responses, and never expose credentials in logs.
- Add mocked HTTP tests for success, timeout, connection failure, HTTP errors, malformed JSON, missing fields, duplicate chunks, and cancellation.
- Document an isolated local development configuration for CPU-only or remote-model use.
Configuration
Introduce configuration equivalents for:
- LightRAG base URL
- API key or auth header source
- query mode
- request timeout
- maximum candidates/chunks
- maximum response bytes or bounded parsing behavior
Secrets must come from environment/configuration and must not be included in traces, exception messages, or committed examples.
Non-Goals
- Do not write KDN knowledge into LightRAG automatically yet.
- Do not call LightRAG from the Scheduler production path yet.
- Do not change the active retrieval backend.
- Do not require CUDA or a local LLM.
- Do not add LightRAG dependencies to Proxy or Instance environments.
Acceptance Criteria
- The client is optional and has no import-time network or model side effects.
- All tests pass using a mock HTTP server or transport.
- CPU-only CI does not require LightRAG, CUDA, a live LLM, Redis, or vLLM.
- LightRAG responses are normalized into canonical retrieval contracts, with unresolved LightRAG IDs clearly marked for Step 3 mapping.
- Cancellation and timeout propagate promptly and do not leave background tasks running.
- Existing embedding retrieval remains the only active production path.
- A manual smoke-test procedure is documented separately from automated tests.
Validation
Run focused client/contract tests plus the Step 1 retrieval compatibility tests. Include actual results in the PR and use Closes #164.
Parent Epic: #162
Depends on: #163
Goal
Add an optional LightRAG REST client behind the retrieval contracts from Step 1. Validate API behavior, configuration, response normalization, and failure handling without changing the production retrieval backend.
Deployment Boundary
LightRAG runs as an independent service. CacheRoute components communicate through a small asynchronous REST adapter. Do not import or initialize LightRAG Core inside Scheduler, KDN, Proxy, or Instance processes in this step.
Scope
LightRAGClientwith connection reuse and explicit timeouts.LightRAGKnowledgeRetrieverthat converts LightRAG responses into backend-neutralRetrievalResultobjects.naiveandmixquery modes through configuration.Configuration
Introduce configuration equivalents for:
Secrets must come from environment/configuration and must not be included in traces, exception messages, or committed examples.
Non-Goals
Acceptance Criteria
Validation
Run focused client/contract tests plus the Step 1 retrieval compatibility tests. Include actual results in the PR and use
Closes #164.