Conversation
…_fts5 for go install Two product bugs reported against v0.1.3 from a corporate-firewall install. 1. DOCSIQ_LLM_* env vars silently ignored without a config file. Viper's AutomaticEnv() + Unmarshal() only reads env for keys that are either explicitly bound via BindEnv or already present in the merged config tree (Viper #761). Of all the LLM keys, only llm.call_timeout was explicitly bound, so DOCSIQ_LLM_PROVIDER, DOCSIQ_LLM_OLLAMA_*, DOCSIQ_LLM_AZURE_*, DOCSIQ_LLM_OPENAI_*, etc. were dropped on the floor for users without ~/.docsiq/config.yaml. Fix: after all SetDefault calls, iterate v.AllKeys() and BindEnv every one. The existing explicit BindEnv list stays — it documents the DOCSIQ_API_KEY shortcut alias for server.api_key and double-binds harmlessly. Adds TestLoad_EnvOverridesLLM as a regression test covering DOCSIQ_LLM_PROVIDER, the Ollama and Azure subtrees, and DOCSIQ_DATA_DIR — all without writing a config file. 2. go install github.com/RandomCodeSpace/docsiq@<ver> produces a binary that fails at runtime with "no such module: fts5" when opening any project store. mattn/go-sqlite3 only enables FTS5 when compiled with -tags=sqlite_fts5; the Makefile passes that, but go install does not pick up Makefile tags. Fix (docs only): docs/getting-started.md updated to document `GOFLAGS='-tags=sqlite_fts5' go install ...@latest` with an explanatory line on why the tag is non-negotiable. README's "Build from source" already shows the tag on `go build` and does not reference `go install`, so it stays. CONTRIBUTING.md does not reference `go install` either. Verification: - make vet, make build, make test all green. - internal/config new test passes. - End-to-end smoke: fresh binary on :37789 with DOCSIQ_LLM_PROVIDER=ollama DOCSIQ_LLM_OLLAMA_EMBED_MODEL=bge-m3 logs "LLM provider initialised provider=ollama model=bge-m3" without a config file — confirms env override path. - Production server on :37777 untouched. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
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.
Summary
Two bugs reported by a user installing v0.1.3 in a corporate environment.
Bug 1 —
DOCSIQ_LLM_*env vars silently ignored without a config file.Viper's
AutomaticEnv()+Unmarshal()only reads env for keys that are explicitly bound viaBindEnv(or already present in the merged config tree) — see Viper #761. Of all the LLM keys, onlyllm.call_timeoutwas bound, soDOCSIQ_LLM_PROVIDER,DOCSIQ_LLM_OLLAMA_*,DOCSIQ_LLM_AZURE_*,DOCSIQ_LLM_OPENAI_*were dropped for users without~/.docsiq/config.yaml.Fix: walk
v.AllKeys()after allSetDefaultcalls andBindEnveach. The existing explicitBindEnvlist stays — it documents theDOCSIQ_API_KEYalias forserver.api_keyand double-binds harmlessly.Bug 2 —
go install ...@v0.1.3produces a binary that fails at runtime.The user hits
unable to open store: no such module: fts5becausemattn/go-sqlite3only enables FTS5 with-tags=sqlite_fts5. The Makefile sets that tag;go installdoesn't pick up Makefile tags. Docs-only fix:docs/getting-started.mdnow showsGOFLAGS='-tags=sqlite_fts5' go install ...@latestwith a one-paragraph explanation of why the tag is required.Files changed (3)
internal/config/config.go—for _, key := range v.AllKeys() { _ = v.BindEnv(key) }after defaults.internal/config/config_test.go— newTestLoad_EnvOverridesLLMregression covering provider, Ollama, Azure, DataDir without a config file.docs/getting-started.md—go installline usesGOFLAGS='-tags=sqlite_fts5'; build-from-checkoutgo buildline gains the tag for consistency.Test plan
make vetclean.make buildclean.make testgreen; newTestLoad_EnvOverridesLLMpasses.:37789withDOCSIQ_LLM_PROVIDER=ollama DOCSIQ_LLM_OLLAMA_EMBED_MODEL=bge-m3and no config file. Server log shows⚙️ LLM provider initialised provider=ollama model=bge-m3— confirms the env value flows into the resolved config.:37777was not touched.Out of scope
go mod vendor) — v0.2.0.mattn/go-sqlite3formodernc.org/sqlite— separate, larger change.documents.file_hash UNIQUEcollision on--force, case-sensitive/api/graph/neighborhood, community-finalize duplicate rows, and Upload SSE 202-vs-partial-fail status — all tracked separately.🤖 Generated with Claude Code