feat(worker): operator settings that survive a reinstall (worker.local.env) - #176
Merged
Conversation
Adding anything to the worker's environment meant editing the container by hand, and the next install from the app silently threw it away - the run command is generated fresh each time, so any -e flag added manually disappeared with the old container. The operator had no way to know until a capability quietly stopped being advertised. The installer now applies `<keys-dir>/../worker.local.env` via --env-file when it exists. That covers web search (SEARCH_ENABLED, TAVILY_API_KEY, SEARCH_MAX_RESULTS, SEARCH_TIMEOUT - all read by the worker binary today) and anything similar later. A file rather than a field in the UI, deliberately. A credential typed into the app would travel through the generated script, and that script is streamed to the install log and rendered on screen. A file the operator writes once never passes through either. The flag goes BEFORE the -e flags this script emits, so script-managed values win. A stale local file must not be able to repoint RPC_URL or a registry address and leave the worker talking to the wrong chain. Windows builds the flag as an array instead of a string: splatting an empty string into a docker argument list leaves a stray empty argument, which docker rejects. Verified: tsc clean, 673 tests, eslint clean, `bash -n` parses the 667-line generated installer, and a worker started from such a file reports the SEARCH_* variables with the chain settings still intact. Worth recording for whoever reads this next: the binary reads SEARCH_ENABLED, with a D. `SEARCH_ENABLE` appears in some docs and is read by nothing - the worker starts cleanly, looks healthy, and never advertises search.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Adding anything to the worker's environment currently means editing the container by hand — and the next install from the app silently throws it away. The run command is generated fresh each time, so a manually-added
-eflag disappears with the old container, and the operator has no way to know until a capability quietly stops being advertised.The installer now applies
<keys-dir>/../worker.local.envvia--env-filewhen it exists.Why a file, not a UI field: a credential typed into the app would travel through the generated script, and that script is streamed to the install log and rendered on screen. A file the operator writes once never passes through either.
Ordering matters: the flag goes before the
-eflags this script emits, so script-managed values win. A stale local file must not be able to repointRPC_URLand leave the worker talking to the wrong chain.Windows builds the flag as an array rather than a string — splatting an empty string into a docker argument list leaves a stray empty arg, which docker rejects.
SEARCH_ENABLED(with a D).strings /bin/workerlistsSEARCH_ENABLED,SEARCH_MAX_RESULTS,SEARCH_TIMEOUT,TAVILY_API_KEY. TheSEARCH_ENABLEspelling that circulates is read by nothing — the worker starts cleanly, looks healthy, and never advertises search. Might be worth correcting wherever that's documented.Verified:
tscclean · 673 tests · eslint clean ·bash -nparses the 667-line generated installer · a worker started from such a file reports theSEARCH_*vars with chain settings intact.