…g exit (#9268)

* fix(guardrails): forward abort telemetry synchronously to avoid a hung exit

Single-step install injects the tracer via NODE_OPTIONS. When it bails out on an
incompatible runtime it fires abort telemetry by spawning the forwarder with
child_process.spawn, then the injected app returns and typically calls
process.exit(). On Node 24.0.0/24.1.x a child still tearing down its stdio pipes
deadlocks process.exit() (fixed upstream in 24.2), so the forwarder keeps the
short-lived process alive until it is killed externally. Because injection is
automatic, an unsupported-runtime customer with short-lived processes gets hangs.

Forward the abort telemetry with spawnSync so the child is fully reaped before we
return and nothing outlives the call to race the exit. The synchronous path runs
only on the non-forced bailout, before any instrumentation is active, so the
forwarder is never traced; the async spawn stays for the post-init `complete`
point. spawnSync exists since Node 0.11.12 and the guardrails still target >=0.8,
which predates the exit bug, so the async path remains the fallback there.

Refs: nodejs/node#63085

* fix(guardrails): bound the synchronous forwarder so it cannot hang the exit

The synchronous bailout path validates only that DD_TELEMETRY_FORWARDER_PATH
exists, then blocks on spawnSync with no timeout. A forwarder or wrapper that
wedges before exiting would hang the injected process before guardrails return
and before the app can reach its own process.exit() — reintroducing the exact
hard hang this change exists to remove. Bound the send with a 1s timeout and
SIGKILL, and log ETIMEDOUT distinctly; the telemetry is best-effort, so a bad
forwarder degrades to a dropped point instead of a stuck process.

* test(guardrails): cover the synchronous forwarder error branches

The spawnSync bailout path logs two failures that had no coverage: a
non-ETIMEDOUT spawn error (a forwarder that exists but cannot execute, e.g.
EACCES) and a non-zero forwarder exit code. Both are reachable and mirror the
async path's handling, so they get real cases beside the existing ETIMEDOUT
test using the same mocked-spawnSync pattern.

…g exit (#9268)

* fix(guardrails): forward abort telemetry synchronously to avoid a hung exit

Single-step install injects the tracer via NODE_OPTIONS. When it bails out on an
incompatible runtime it fires abort telemetry by spawning the forwarder with
child_process.spawn, then the injected app returns and typically calls
process.exit(). On Node 24.0.0/24.1.x a child still tearing down its stdio pipes
deadlocks process.exit() (fixed upstream in 24.2), so the forwarder keeps the
short-lived process alive until it is killed externally. Because injection is
automatic, an unsupported-runtime customer with short-lived processes gets hangs.

Forward the abort telemetry with spawnSync so the child is fully reaped before we
return and nothing outlives the call to race the exit. The synchronous path runs
only on the non-forced bailout, before any instrumentation is active, so the
forwarder is never traced; the async spawn stays for the post-init `complete`
point. spawnSync exists since Node 0.11.12 and the guardrails still target >=0.8,
which predates the exit bug, so the async path remains the fallback there.

Refs: nodejs/node#63085

* fix(guardrails): bound the synchronous forwarder so it cannot hang the exit

The synchronous bailout path validates only that DD_TELEMETRY_FORWARDER_PATH
exists, then blocks on spawnSync with no timeout. A forwarder or wrapper that
wedges before exiting would hang the injected process before guardrails return
and before the app can reach its own process.exit() — reintroducing the exact
hard hang this change exists to remove. Bound the send with a 1s timeout and
SIGKILL, and log ETIMEDOUT distinctly; the telemetry is best-effort, so a bad
forwarder degrades to a dropped point instead of a stuck process.

* test(guardrails): cover the synchronous forwarder error branches

The spawnSync bailout path logs two failures that had no coverage: a
non-ETIMEDOUT spawn error (a forwarder that exists but cannot execute, e.g.
EACCES) and a non-zero forwarder exit code. Both are reachable and mirror the
async path's handling, so they get real cases beside the existing ETIMEDOUT
test using the same mocked-spawnSync pattern.

…g exit (#9268)

* fix(guardrails): forward abort telemetry synchronously to avoid a hung exit

Single-step install injects the tracer via NODE_OPTIONS. When it bails out on an
incompatible runtime it fires abort telemetry by spawning the forwarder with
child_process.spawn, then the injected app returns and typically calls
process.exit(). On Node 24.0.0/24.1.x a child still tearing down its stdio pipes
deadlocks process.exit() (fixed upstream in 24.2), so the forwarder keeps the
short-lived process alive until it is killed externally. Because injection is
automatic, an unsupported-runtime customer with short-lived processes gets hangs.

Forward the abort telemetry with spawnSync so the child is fully reaped before we
return and nothing outlives the call to race the exit. The synchronous path runs
only on the non-forced bailout, before any instrumentation is active, so the
forwarder is never traced; the async spawn stays for the post-init `complete`
point. spawnSync exists since Node 0.11.12 and the guardrails still target >=0.8,
which predates the exit bug, so the async path remains the fallback there.

Refs: nodejs/node#63085

* fix(guardrails): bound the synchronous forwarder so it cannot hang the exit

The synchronous bailout path validates only that DD_TELEMETRY_FORWARDER_PATH
exists, then blocks on spawnSync with no timeout. A forwarder or wrapper that
wedges before exiting would hang the injected process before guardrails return
and before the app can reach its own process.exit() — reintroducing the exact
hard hang this change exists to remove. Bound the send with a 1s timeout and
SIGKILL, and log ETIMEDOUT distinctly; the telemetry is best-effort, so a bad
forwarder degrades to a dropped point instead of a stuck process.

* test(guardrails): cover the synchronous forwarder error branches

The spawnSync bailout path logs two failures that had no coverage: a
non-ETIMEDOUT spawn error (a forwarder that exists but cannot execute, e.g.
EACCES) and a non-zero forwarder exit code. Both are reachable and mirror the
async path's handling, so they get real cases beside the existing ETIMEDOUT
test using the same mocked-spawnSync pattern.

…g exit (#9268)

* fix(guardrails): forward abort telemetry synchronously to avoid a hung exit

Single-step install injects the tracer via NODE_OPTIONS. When it bails out on an
incompatible runtime it fires abort telemetry by spawning the forwarder with
child_process.spawn, then the injected app returns and typically calls
process.exit(). On Node 24.0.0/24.1.x a child still tearing down its stdio pipes
deadlocks process.exit() (fixed upstream in 24.2), so the forwarder keeps the
short-lived process alive until it is killed externally. Because injection is
automatic, an unsupported-runtime customer with short-lived processes gets hangs.

Forward the abort telemetry with spawnSync so the child is fully reaped before we
return and nothing outlives the call to race the exit. The synchronous path runs
only on the non-forced bailout, before any instrumentation is active, so the
forwarder is never traced; the async spawn stays for the post-init `complete`
point. spawnSync exists since Node 0.11.12 and the guardrails still target >=0.8,
which predates the exit bug, so the async path remains the fallback there.

Refs: nodejs/node#63085

* fix(guardrails): bound the synchronous forwarder so it cannot hang the exit

The synchronous bailout path validates only that DD_TELEMETRY_FORWARDER_PATH
exists, then blocks on spawnSync with no timeout. A forwarder or wrapper that
wedges before exiting would hang the injected process before guardrails return
and before the app can reach its own process.exit() — reintroducing the exact
hard hang this change exists to remove. Bound the send with a 1s timeout and
SIGKILL, and log ETIMEDOUT distinctly; the telemetry is best-effort, so a bad
forwarder degrades to a dropped point instead of a stuck process.

* test(guardrails): cover the synchronous forwarder error branches

The spawnSync bailout path logs two failures that had no coverage: a
non-ETIMEDOUT spawn error (a forwarder that exists but cannot execute, e.g.
EACCES) and a non-zero forwarder exit code. Both are reachable and mirror the
async path's handling, so they get real cases beside the existing ETIMEDOUT
test using the same mocked-spawnSync pattern.