[
https://issues.apache.org/jira/browse/SOLR-18650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-18650:
-------------------------------
Description:
*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.
🤖 AI Assisted
was:
*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
> 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.
> 🤖 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]
