Repository navigation
fix(core): own-property {env:} lookup in ConfigVariable.substitute - #806
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 7 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 72 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
|
The following comment was made by an LLM, it may be inaccurate: |
Fixes #804
Problem
ConfigVariable.substitute(packages/core/src/config/variable.ts) resolved{env:NAME}with a plain lookup —(input.env?.[name] ?? process.env[name]) || fallback— which reads through the prototype chain. For prototype names the reference resolved to the inherited member instead of "unset":{env:constructor}injectedfunction Object() { [native code] },{env:toString}/{env:hasOwnProperty}/{env:valueOf}injected function sources,{env:__proto__}injected[object Object], and any:-fallback was ignored for all of them — silently baking that text into parsed config from any config source.Fix
Own-property resolution for both sources, following the established
Object.hasOwnprecedent (#747 / #774 / #792):input.env && Object.hasOwn(input.env, name) ? input.env[name] : undefinedObject.hasOwn(process.env, name) ? process.env[name] : undefinedThe existing
|| fallbackstep is unchanged, so genuinely set variables (including a variable genuinely set under a prototype name in the supplied env, and the documented unset-or-empty:-fallback behavior) behave exactly as before. No{file:}or comment/escaping behavior is touched.Tests
New test in
packages/core/test/config/config.test.ts— "resolves env references by own property, not through the prototype chain" — pins all five names (constructor,toString,hasOwnProperty,valueOf,__proto__) on both paths:""/ the:-fallback""/ the:-fallbackVerification
~/git/fleet/2966-804-env-proto):bun test test/config/config.test.tsfrompackages/core— 59 pass, 0 fail (new test included).Filed from queue task 2966 (repo-health-opencode-pilot, Lane A).
Need help on this PR? Tag
@codesmith-botwith what you need.