RCA: ChildProcessManager stderr — AWS SDK v2 maintenance mode notice

Overview#

What Happened#

cupixworks-any-mesh-agent가 mesh 추출 child process를 fork할 때마다 Node.js가 aws-sdk v2 패키지에 대한 maintenance-mode 경고를 stderr로 출력한다. ChildProcessManager.setupEventHandlers의 stderr.on('data') 핸들러가 이 출력을 logger.error()로 기록하기 때문에, 단순 deprecation 경고가 Datadog에서 status:error로 집계되어 error cluster로 분류되었다. 실제 작업 실패는 아니다.

Quick Facts#

Affected Teams#

Timeline#

1. 2026-06-24 13:50:34 KST — cupixworks-any-mesh-agent가 mesh-extractor child process를 fork. Node.js가 v2 SDK deprecation 경고를 stderr로 발행. ChildProcessManager가 line별로 logger.error() 호출 → Datadog에 status:error 5건 기록 (cluster 묶음).
2. 2026-06-24 11:17, 11:41, 12:28, 12:44, 13:50 KST — 동일 패턴 반복. child process fork할 때마다 동일 stderr 메시지가 error로 기록됨 (24시간 동안 최소 5회 관측).

Error Log#

Datadog Logs

ChildProcessManager::setupEventHandlers | Child process stderr: (node:48) NOTE: The AWS SDK for JavaScript (v2) will enter maintenance mode

Impact#

• Service: cupixworks-any-mesh-agent
• Team: demokr
• 발생 횟수: 1 (대표 로그); 실제로는 child process fork 시마다 5줄씩 발생 (24h 동안 5회 fork 관측됨)
• 최초 발생: 2026-06-24 13:50 KST
• 최근 발생: 2026-06-24 13:50 KST

Root Cause Summary#

@agents/base와 cupix-tesla-mesh-agent가 의존하는 aws-sdk@2.1599.0(v2)이 Node.js 런타임에서 maintenance-mode deprecation 경고를 stderr에 출력한다. ChildProcessManager는 mesh-extractor child process를 stdio: 'pipe'로 fork한 뒤 child의 stderr 출력을 모두 logger.error()로 전달하도록 구현되어 있다(packages/base/src/manager/child-process.manager.ts:138-141). 결과적으로 single deprecation banner 한 번이 5줄로 분할되어 모두 status:error 로그로 기록되고, error-sweeper가 이를 cluster로 식별했다. 실제 mesh extraction은 정상 완료된다 — false-positive error 로그다.

Technical Analysis#

Code Path#

• Entry point: packages/cupix-tesla-mesh-agent/src/manager/mesh-extract.manager.ts:38 — MeshExtractManager constructor가 ChildProcessManager를 생성.
• Fork: packages/base/src/manager/child-process.manager.ts:74-77 — fork(actualScriptPath, { stdio: ['inherit', stdOut, stdErr, 'ipc'] }).
• stderr handler 설정: packages/base/src/manager/child-process.manager.ts:138-141.
• Failure point (logging-only, not functional): packages/base/src/manager/child-process.manager.ts:140 — child의 모든 stderr 라인을 logger.error()로 기록.

this.process.stderr?.on('data', (data: Buffer) => {
    const text = data.toString();
    logger.error(`ChildProcessManager::setupEventHandlers | Child process stderr: ${text}`);
});

constructor(options?: ChildProcessOptions) {
    this.childProcessManager = new ChildProcessManager(__dirname, 'process/mesh-extractor.process', options);
}

"dependencies": {
    "aws-sdk": "2.1599.0",
    ...
}

기대 동작 vs 실제 동작:

• 기대: child process의 stderr는 진짜 에러(uncaught exception, native crash 등)만 error 레벨로 기록되어야 한다. Node.js process warning((node:NN) NOTE: ...)은 정보성 메시지이므로 warn 또는 info 수준이 적절하다.
• 실제: stderr로 들어오는 모든 텍스트가 무조건 logger.error()로 전달된다. Node.js는 deprecation banner를 5줄에 걸쳐 stderr에 한 번에 쓰고, 핸들러가 chunk 단위로 호출되어 각 라인이 개별 error log entry가 된다.

Log Evidence#

Datadog query:

service:cupixworks-any-mesh-agent status:error "ChildProcessManager::setupEventHandlers"

24시간 동안 동일 child process fork 이벤트가 최소 5회 발생했으며, 각 fork마다 동일한 5줄 banner가 error로 기록됨:

2026-06-24 13:50:34  error  ChildProcessManager::setupEventHandlers | Child process stderr: (node:48) NOTE: The AWS SDK for JavaScript (v2) will enter maintenance mode
2026-06-24 13:50:34  error  ChildProcessManager::setupEventHandlers | Child process stderr: on September 8, 2024 and reach end-of-support on September 8, 2025.
2026-06-24 13:50:34  error  ChildProcessManager::setupEventHandlers | Child process stderr: Please migrate your code to use AWS SDK for JavaScript (v3).
2026-06-24 13:50:34  error  ChildProcessManager::setupEventHandlers | Child process stderr: For more information, check blog post at https://a.co/cUPnyil
2026-06-24 13:50:34  error  ChildProcessManager::setupEventHandlers | Child process stderr: (Use `node --trace-warnings ...` to show where the warning was created)

동일 fork 패턴이 11:17, 11:41, 12:28, 12:44, 13:50 KST에 반복됨. 메시지 텍스트는 Node.js가 AWS SDK v2 로딩 시 출력하는 공식 deprecation banner와 정확히 일치 (AWS 공식 blog: a.co/cUPnyil).

Hypotheses Considered#

Fix Recommendation#

즉시 조치 (Critical)#

운영상 즉시 위험은 없음 (false-positive). 단, 진짜 에러를 가리는 노이즈가 되므로 다음을 권장:

• 파일: packages/base/src/manager/child-process.manager.ts:138-141.
• 방향: child stderr에서 Node.js process warning 패턴((node:\d+) NOTE:, (node:\d+) Warning:, DeprecationWarning, (Use node --trace-warnings ...), 후속 banner 라인)을 인식하여 logger.warn() 또는 logger.info()로 다운그레이드한다. 그 외 일반 stderr는 기존대로 logger.error() 유지. 멀티라인 banner를 한 entry로 buffer하는 것도 고려.
• 근거: 실제 process crash나 native error는 SIGNAL/exit code(close/exit 핸들러)로도 잡히므로 stderr-only 경고를 error로 올릴 필요가 없다.

단기 개선 (1주 이내)#

• aws-sdk v2 → v3 마이그레이션 계획 수립. v2는 2024-09-08부터 maintenance mode, 2025-09-08 end-of-support였으므로 이미 EOL이 지난 상태.
• 영향 패키지: packages/base/package.json (aws-sdk: 2.1599.0), packages/cupix-pano-postprocessor/package.json (aws-sdk: 2.1599.0), packages/cupix-tesla-compute-agent/package.json (aws-sdk: ^2.1407.0), 그리고 transitive 의존인 @cupix/app-mesh-extractor-v2.
• 임시 우회로 child process 진입점에서 process.removeAllListeners('warning') 또는 환경변수 AWS_SDK_JS_SUPPRESS_MAINTENANCE_MODE_MESSAGE=1을 설정해 banner 자체를 억제할 수 있다 (AWS 공식 제공 옵션). 단, 이는 근본 해결이 아닌 잡음 차단 목적의 임시 조치이며, v3 마이그레이션 완료 시 제거한다.

장기 개선 (재발 방지)#

• 의존성 EOL 모니터링: 모든 agent 패키지의 aws-sdk, node, tsx 등 핵심 라이브러리에 대해 dependabot/renovate 같은 자동 알림 도입.
• Child process stderr 로깅 정책: 모든 ChildProcessManager 사용처에서 동일한 패턴이 발생하므로(MeshExtractManager 외 다른 *Manager에서도 reuse), base 패키지에서 한 번 수정하면 모든 agent에 전파됨. ChildProcessManager에 "warn-pattern matcher" 옵션을 노출하여 agent별로 추가 패턴을 등록할 수 있게 한다.

Monitoring#

추가/유지할 Datadog 쿼리:

• AWS SDK v2 banner 발생률 추적 (수정 후 0으로 떨어져야 함):

service:cupixworks-any-mesh-agent "AWS SDK for JavaScript (v2)"

• 진짜 child process 실패만 분리해서 모니터:

service:cupixworks-any-mesh-agent status:error "ChildProcessManager::setupEventHandlers | Child process closed"

• mesh-agent 전체 에러율 (banner 노이즈 제거 후의 baseline 확인용):

service:cupixworks-any-mesh-agent status:error -"AWS SDK for JavaScript" -"Use `node --trace-warnings"

Risk Assessment#

• Risk level: low — 기능적 영향 없음. 다만 error 로그 노이즈가 누적되어 진짜 에러 탐지를 방해하고, on-call alerting의 SNR을 낮춤.
• 예상 복잡도: trivial (즉시 조치: stderr → warn 다운그레이드 1곳). 장기 v3 마이그레이션은 standard.