Jan Høydahl created SOLR-18650:
----------------------------------
Summary: 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
*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]
