[
https://issues.apache.org/jira/browse/SOLR-18650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18143925#comment-18143925
]
Jan Høydahl commented on SOLR-18650:
------------------------------------
[~epugh] I'm not sure what the "correct" answer to this is.
Here is my thinking:
When someone runs an example, they are not in production, they are on their dev
machine in a Terminal shell.
Most users will not have set any {{SOLR_XX}} env.vars permanently in their
rc-files, so any {{SOLR_XX}} envs present will be temporary and deliberate.
The linux {{bin/solr}} script lets the example inherit everything. 95% of our
users are on linux and have been happy with that behavior. Thus I think we
should mimic the same over to the windows side. Or?
> RunExampleTool drops every SOLR_* variable when starting an example on Windows
> ------------------------------------------------------------------------------
>
> Key: SOLR-18650
> URL: https://issues.apache.org/jira/browse/SOLR-18650
> Project: Solr
> Issue Type: Bug
> Components: cli
> Reporter: Jan Høydahl
> Priority: Major
> Labels: cats, windows
>
> *Found by CATS*, the cross-platform CLI test framework proposed in SOLR-18642
> — see [PR #5323|https://github.com/apache/solr/pull/5323]. {{ExampleTest}}
> there is gated {{@EnabledOnShell(Shell.BASH)}} because of this, so the
> example flow has no Windows coverage at all. A fix can land before CATS is
> merged or after; if it lands first, please also drop that gate on that PR.
> h3. The asymmetry
> {{RunExampleTool#startSolr}} builds a fresh environment for the child node on
> Windows and copies across only the variables that are *not* named {{EXAMPLE}}
> and do not start with {{SOLR_}} ({{RunExampleTool.java:1081}}):
> {code:java}
> if (envVarVal != null && !"EXAMPLE".equals(envVar) &&
> !envVar.startsWith("SOLR_")) {
> startEnv.put(envVar, envVarVal);
> }
> {code}
> The non-Windows branch passes no environment map at all, so the child simply
> inherits the parent's. The pruning dates to SOLR-7847 (2015), when the
> run-example logic moved out of the scripts into Java; its comment says only
> that the child "seems to be inheriting the environment that launched this
> app, so we have to prune out env vars that may cause issues". It is not
> related to the recent Windows example work in SOLR-17595 or SOLR-17772.
> h3. What is actually lost
> Narrower than it first looks, because the child {{bin\solr.cmd}} sources its
> include file itself ({{solr.cmd:51\-52}}), so anything set in {{solr.in.cmd}}
> comes back. Two things do not survive.
> *Environment-set variables.* Any {{SOLR_*}} exported in the user's shell —
> {{SOLR_HEAP}}, {{SOLR_OPTS}}, {{SOLR_LOGS_DIR}}, {{SOLR_PID_DIR}} and the
> rest — is silently ignored for example nodes, while the identical command
> honours them on Linux and macOS.
> *The include file itself.* {{SOLR_INCLUDE}} is a {{SOLR_*}} variable, so it
> is pruned too. A user pointing at a custom include file gets the stock
> {{%SOLR_TIP%\bin\solr.in.cmd}} instead, with no warning, and the example runs
> under configuration they did not ask for.
> h3. Effect on testing
> The harness gives each test class its own {{SOLR_PID_DIR}} and a
> {{solr.process.scan.marker}}, both by environment. An example's nodes on
> Windows inherit neither, so they cannot be discovered, owned or stopped, and
> the class teardown's leak check fails. That is why the whole suite is
> bash-only rather than one test being skipped.
> h3. Suggested fix
> Replace the blanket prefix test with an allow-list, or exclude only the
> specific variables that genuinely confuse a child node. If any exclusion is
> still needed, naming it and saying why would keep the next reader from having
> to guess, which the current comment does not.
> 🤖 AI Assisted
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
