fix(selfhost): deliver MULTICA_LLM_* to the backend and log the layer state - #6240
Open
forrestchang wants to merge 2 commits into
Open
fix(selfhost): deliver MULTICA_LLM_* to the backend and log the layer state#6240forrestchang wants to merge 2 commits into
forrestchang wants to merge 2 commits into
Conversation
… state Chat auto-titling and chat follow-up suggestions are gated on the server-side LLM layer, which reads MULTICA_LLM_API_KEY / MULTICA_LLM_BASE_URL through os.Getenv. The self-host compose file enumerates backend environment explicitly and has no env_file, and those three vars were not in the list — so setting them in .env did nothing, the container never saw them, and the layer was off on every compose deployment regardless of configuration. .env.example documents them, which made it look configurable. That was survivable while quick actions were generated by the daemon's own provider pass, which needed no server key. MUL-5573 moved generation server- side and removed the daemon path, so on those deployments the feature stopped appearing entirely rather than degrading. Adds the passthrough, and one startup line reporting whether the layer is enabled. Every consumer degrades silently by design, so without that line an unset key is indistinguishable from a broken feature — which is exactly how this surfaced. Helm already supports it through the operator-managed Secret; values.yaml now says so instead of leaving it undocumented. Co-authored-by: multica-agent <github@multica.ai>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The only existing coverage called the generator directly. Everything between the completion callback and the pills landing on the row — the eligibility decision, the chat:done flag, the detached dispatch — went untested, which is exactly the stretch you have to rule out when the feature 'just does not appear'. Co-authored-by: multica-agent <github@multica.ai>
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
Adds
MULTICA_LLM_API_KEY/MULTICA_LLM_BASE_URL/MULTICA_LLM_DEFAULT_MODELto the self-host compose backend environment, and logs one line at startup saying whether the LLM layer came up enabled.Why
docker-compose.selfhost.ymlenumerates the backend's environment explicitly and has noenv_file:. The threeMULTICA_LLM_*vars were not in that list, so setting them in.envhad no effect — they never reached the container..env.exampledocuments all three, which made the layer look configurable when on compose it could not be turned on at all.Everything gated on that layer was therefore permanently off for compose deployments:
This was survivable while quick actions were generated by the daemon's own provider pass, which needs no server-side key. MUL-5573 (#6214) moved generation server-side and removed the daemon path — so on these deployments the feature went from working to absent, with no error anywhere.
Helm is unaffected in capability: it mounts an operator-managed Secret with
envFrom, so the keys can already be supplied. It just wasn't documented.values.yamlnow says so.The startup line
Every consumer of this layer degrades quietly on purpose, so an unset key looked identical to a broken feature. That is precisely how this was reported — "the feature stopped working" — with nothing in the logs to distinguish the two. One line makes it self-diagnosing.
Verification
go build ./...,go vet,gofmtclean.internal/handlerandinternal/servicesuites pass (run against a throwaway migrated database, dropped afterwards).llm.Newyields the same disabled client as before.