fix(adapter-ticktick): authenticate against a key-protected Qdrant - #22
Merged
Conversation
A Qdrant started with QDRANT__SERVICE__API_KEY answers 401 on every path except '/'. The adapter sent no credential, so checkHealth() fell into its catch-all and reported "Qdrant not reachable" for a service that was up and merely refusing the request. Retrieval then degraded to keyword-only without surfacing an error, which is the failure mode that hides: every query still returns results, just worse ones. httpJson now sends an 'api-key' header when QDRANT_API_KEY is set. It is scoped with url.startsWith(QDRANT_URL) on purpose — the same helper also calls Ollama, which must never receive the key. checkHealth() now distinguishes 401/403 from an unreachable service and names QDRANT_API_KEY in the message, so the next person reads "set the key" instead of hunting ports and containers. Tests cover all three paths: the key reaches Qdrant, it does not leak to Ollama, and a real connection failure still reports as unreachable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
httpJsonnow sends anapi-keyheader whenQDRANT_API_KEYis set, andcheckHealth()tells an auth refusal apart from an unreachable service.Why
A Qdrant started with
QDRANT__SERVICE__API_KEYanswers 401 on every path except/. The adapter sent no credential, socheckHealth()hit its catch-all and reported "Qdrant not reachable at http://localhost:6333" — for a service that was up and simply refusing the request.That misdiagnosis is the expensive part.
ats doctorsaid "not reachable", which sends you hunting ports, containers and firewall rules while the fix is one environment variable. Meanwhile retrieval silently degraded to keyword-only: every query still returned results, just worse ones, with no error anywhere.Notes
url.startsWith(QDRANT_URL)deliberately — the same helper also calls Ollama, which must never receive the key.QDRANT_API_KEYunset the behaviour is byte-for-byte what it was.deploy/README.mddocuments the variable alongside the existing Qdrant/Ollama entries.Tests
Three cases in
packages/adapter-ticktick/test/qdrant-auth.test.js: the key reaches Qdrant, it does not leak to Ollama, and a genuine connection failure still reports as unreachable.npm run lint,check:pii,check:claimsclean ·test:fast299/299.Release
Versions are untouched — packages here move in lockstep (
0.7.1 → 0.8.0 → 0.8.1 → 0.9.0 → 0.10.0), so the bump belongs to a deliberate release, not this PR.