Logger writes default LOG_LEVEL to global process.env, leaking into other extensions' child processes

Open
  • Is something wrong?
#173 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
javascript, node.js
Domain
devtools

Research direction

Start with the logging helper and setLevel implementation described in dist/extension.js, then locate the corresponding extension source and its tests or activation entry point. Verify that choosing the default or configured level no longer mutates global process.env, and reproduce the extension-host child-process check to confirm unrelated processes do not inherit LOG_LEVEL.

Written by the indexing model from the issue text.

Description

in progress

Summary

On activation, the extension's bundled logger writes a default LOG_LEVEL value onto the global process.env of the VS Code extension host. Because all extensions share that single host process, the mutated environment is then inherited by every child process any other extension spawns afterwards. In practice this silently sets LOG_LEVEL=1 for unrelated tooling, e.g. the Python extension's pytest test runner and language-server tool processes.

Environment

  • Splunk extension version: 0.3.5
  • VS Code: 1.126.0
  • OS: macOS (darwin, arm64)

Root cause

dist/extension.js contains a logging helper with this level enum and setter (deminified):

const levels = { ALL: 4, INFO: 3, WARN: 2, ERROR: 1, NONE: 0 };

function setLevel(e) {
  if (isString(e) && levels.hasOwnProperty(e)) process.env.LOG_LEVEL = levels[e];
  else if (!isNaN(parseInt(e, 10)) && keyOf(parseInt(e, 10), levels)) process.env.LOG_LEVEL = e;
  else process.env.LOG_LEVEL = levels.ERROR; // default -> 1
}

if (process.env.LOG_LEVEL) setLevel(process.env.LOG_LEVEL); // normalises and writes back
// else falls through to the ERROR (1) default

The problem is not the logger using a LOG_LEVEL config; it is that the value is written back onto the shared, global process.env rather than kept internal to the logger. The extension host is a single long-lived process shared by all extensions, so this mutation leaks out to every subsequently spawned child process across the whole window.

Impact / observed behaviour

With the Splunk extension enabled, inspecting the environment of processes the Python extension forks shows LOG_LEVEL=1, even though it is set nowhere in the user's shell, .env, python.envFile, terminal.integrated.env, or settings.json:

# ps eww on macOS reports each process's environment as it was at exec time
extension host (Code Helper (Plugin))   -> no LOG_LEVEL
python tool servers / pytest test runner -> LOG_LEVEL=1   (inherited)

The extension host itself launched without LOG_LEVEL; the variable only appears in children forked after activation, which pins the source to a runtime mutation of process.env inside the host. This breaks any tool that reads LOG_LEVEL under a different convention. Concretely it broke our pytest setup, because our application/test code interprets LOG_LEVEL as a Python logging level, not as the Splunk enum where 1 means ERROR.

Steps to reproduce

  1. Install the Splunk extension and reload the window.
  2. In any workspace using the Python extension's testing integration, run the tests (or any forked tool server).
  3. Inspect the test runner process environment (e.g. ps eww -p <pid> on macOS) and observe LOG_LEVEL=1, which was not set by the user anywhere.

Suggested fix

Keep the log level internal to the logger instead of writing it to process.env:

  • Store the configured/default level in a module-scoped variable (or read process.env.LOG_LEVEL without writing it back), rather than assigning process.env.LOG_LEVEL.
  • If an env var must be used for child processes the extension itself spawns, pass it via a scoped env option on that specific spawn/exec call rather than mutating the shared global process.env.
Dominant language
Python
Stars
97
Forks
27
Avg merge
3d 24m
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from splunk/vscode-extension-splunk

All issues in splunk/vscode-extension-splunk

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.