SEA + cluster.fork on Windows prepends executable path into worker process.argv (breaks argv parsing)
まだ誰も着手していません。
- 主要言語
- JavaScript
- スター
- 122k
- フォーク
- 37.3k
- 平均マージ
- 4日 2時間
- マージ済み PR(30日)
- 283
説明
Version
v24.15.0
Platform
Microsoft Windows NT 10.0.26200.0 x64
Subsystem
single executable applications (SEA), cluster.fork
What steps will reproduce the bug?
Minimal reproduction idea
- Build a SEA executable whose entry:
- Prints
process.pid, role,process.execPath, andprocess.argv.slice(2) - If primary:
cluster.fork()one worker - If worker: print argv then exit
- Prints
- Run executable with user args, for example:
app.exe command --flag value - Compare primary vs worker argv
slice(2).
Primary shows:
["foo","bar"]
Worker shows:
["X:\\...\\app.exe","foo","bar"]
Node.js versions:
- v24.15.0 (reproducible)
- v22.16.0 (reproducible)
- Historically observed since Node 20 era in our project
How often does it reproduce? Is there a required condition?
100% reproducible under these conditions: (1) the application is built as a SEA executable, (2) the primary process uses cluster.fork() to spawn workers, (3) tested on Windows (Linux not verified). Running the same logic with plain node script.mjs does not reproduce the issue — the extra token only appears in SEA-built worker processes.
What is the expected behavior? Why is that the expected behavior?
Observed pattern:
- Primary process
process.argv.slice(2):
["command","--flag","value"] - Worker process
process.argv.slice(2):
["X:\\path\\to\\app.exe","command","--flag","value"]
Expected behavior
Worker processes in SEA mode should see the same user command arguments as primary for process.argv.slice(2), without an injected executable path token.
What do you see instead?
Actual behavior
Worker process argv includes an extra executable path token before actual user arguments.
Additional information
Control test
Running equivalent script without SEA (node script.mjs foo bar) does not show this divergence.
Impact
- Breaks multi-process startup paths in production for SEA apps using argv-based command routing.
- Particularly problematic when a process model uses cluster workers that execute the same CLI entrypoint.
Current workaround
Application-side argv normalization — filter any token in process.argv.slice(2) that equals process.execPath before handing off to the command parser:
import path from 'node:path';
function normalizePathname(p) {
return path.resolve(p).toLowerCase();
}
function isSelfExecutableArg(arg) {
if (typeof arg !== 'string' || arg.trim() === '' || arg.startsWith('-')) {
return false;
}
return normalizePathname(arg) === normalizePathname(process.execPath);
}
function normalizeArgv(rawArgv) {
return rawArgv.filter(arg => !isSelfExecutableArg(arg));
}
// Usage
const argv = normalizeArgv(process.argv.slice(2));
Key points:
- Case-insensitive path comparison is required on Windows (
path.resolve+.toLowerCase()). - The filter must skip tokens starting with
-to avoid accidentally dropping flags that happen to match. - The injected token can appear anywhere in
slice(2), not just at index 0, so a.filterover the full array is safer than removing index 0 unconditionally.
This avoids the crash but seems like a workaround for runtime behavior that may be unintended.
Additional notes
If needed, I can provide a complete minimal repro repository.
Signed-off-by
GitHub Copilot
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、issue で説明されている SEA 実行可能ファイルをビルドし、Windows 上で primary と cluster.fork() worker の process.argv.slice(2) を比較します。process.argv を構築する SEA worker の起動パスを追跡します。worker が注入された実行可能ファイルのパスなしで primary のユーザー引数を保持し、非 SEA の対照ケースも引き続きパスすれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- javascript, nodejs
- 領域
- backend, operating-systems
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 48/100