[APPS-2792] Prototype: local Node execution for backend functions

[tyffical]

⚠️ Early prototype for design-doc discussion, not ready to merge. Stacked on #460 (the ssr:true fix this prototype's own test depends on).

Motivation

• npm run dev bundles *.backend.ts functions locally today, but executes them by round-tripping 100% of the work to Datadog's cloud (preview-async + long-poll). No Deno or Node runtime executes the function on the developer's machine. Worst case (a hanging function) takes up to ~5 minutes before timing out.
• Getting a console.log back to the developer today requires the full cloud-side round trip to complete first — no real-time feedback.
• Node is already required for npm/Vite; a local execution mode avoids requiring a second (Deno) runtime install.
• Distinct from APPS-2789 (Tiffany, in progress), which only speeds up the existing cloud-side round trip and still spawns Deno there.
• APPS-2792

Architecture

Child process (fork())                 Parent process (Vite plugin)
runs bundled *.backend.ts as main($)
   │
   │ $.Actions.foo.bar({inputs, connectionId})
   │   → Proxy ported from the actionplatform Deno script template
   │     (no Deno dependency in this logic — copies over verbatim)
   │   → child.send() via fork()'s built-in IPC channel:
   │     {id, fqn, inputs, connectionId}
   ├───────────────────────────────────────▶  validate connectionId,
   │                                          then call the real single-
   │                                          action execution endpoint
   │                                          (STUBBED — doesn't exist
   │                                          yet, see Out of Scope)
   │                                                │
   │◀───────────────────────────  process.on('message', {id, type, result})
   │
   │ resolves/rejects the $.Actions promise, continues
   ▼
result flows back up, wrapped as the existing ExecuteActionResponse
{success:true, result:{data}} | {success:false, error} — same contract
as today's cloud round-trip, no protocol change.

Full design doc, including the execution-model tradeoff analysis (child_process.fork() vs worker_threads, empirically measured — see QA below), sandboxing, secrets handling, backward compatibility plan, and timeline: .plans/high-code-apps-local-node-execution-design.md (dd-source repo, not yet published to Confluence).

Changes

What changed	File
New: forks a child process to run a bundled backend function locally, proxying $.Actions calls back to the parent	packages/plugins/apps/src/vite/local-execution.ts
New: the forked child's entry point — ports the $.Actions Proxy logic from the actionplatform Deno script template	packages/plugins/apps/src/vite/local-exec-child.js
New: real, unmocked integration test — actual vite.build(), actual getBaseBackendBuildConfig/generateDevVirtualEntryContent, against a real .backend.ts fixture on disk	packages/plugins/apps/src/vite/local-execution.integration.test.ts

Not included: wiring into createDevServerMiddleware — this prototype validates the execution mechanics only, deliberately not touching the real request path yet.

QA Instructions

yarn install
BUILD_PLUGINS_ENV=test FORCE_COLOR=true JEST_CONFIG_TRANSPILE_ONLY=true VITE_CJS_IGNORE_WARNING=true NODE_OPTIONS="--experimental-vm-modules" yarn workspace @dd/tests exec jest --config jest.config.ts packages/plugins/apps/src/vite/local-execution.integration.test.ts
# Expected: 2 passed, 2 total ✅ VERIFIED

BUILD_PLUGINS_ENV=test FORCE_COLOR=true JEST_CONFIG_TRANSPILE_ONLY=true VITE_CJS_IGNORE_WARNING=true NODE_OPTIONS="--experimental-vm-modules" yarn workspace @dd/tests exec jest --config jest.config.ts packages/plugins/apps
# Expected: 23 test suites, 279 tests, all passing — confirms no regression to the existing dev-server.ts path ✅ VERIFIED

cd packages/plugins/apps && npx tsc -b tsconfig.client.json --emitDeclarationOnly && npx tsc --noEmit
# Expected: no output, clean exit ✅ VERIFIED

Real, measured latency numbers (from a separate throwaway benchmark harness, not part of this PR's test suite — 50 iterations): child_process.fork() p50/p95/p99 = 36.0/37.3/40.4ms vs. worker_threads = 10.0/10.5/13.2ms. Both dramatically faster than today's multi-second-to-multi-minute cloud round trip regardless of which wins; see the design doc's Execution Model section for the full tradeoff discussion (this PR uses fork(), but that choice isn't fully closed out yet).

Manual QA — not yet possible, and that's expected

No manual local or staging QA for this PR specifically: createDevServerMiddleware doesn't call anything in this file, so there's no npm run dev request path that reaches executeScriptLocally() today — nothing a human can click through yet, on any environment. The integration test above is the closest thing to manual QA currently possible: it exercises the real bundler and a real forked child process end-to-end, not mocked. Real local + staging manual QA becomes possible once Milestone 2 (handleExecuteAction integration, tracked in a follow-up PR) actually wires this into the dev server.

Blast Radius

• No production code path is touched. This adds new, unused files only — createDevServerMiddleware is unmodified, so npm run dev's actual behavior is unchanged by this PR.
• No feature flag needed yet, since nothing is wired up. A flag/rollout mechanism is discussed in the design doc for when this is actually integrated.
• Risk: none to existing behavior (additive-only, unreferenced code). Risk profile for the eventual real integration is covered in depth in the design doc (Sandboxing, Secrets Handling, Prod-Parity sections).

Out of Scope / Follow-ups

Item	Status	Next step
Harden the fork/IPC path (signal reporting, shutdown cleanup, edge-case coverage)	Done	DataDog/build-plugins#471, stacked on this PR
Wiring into createDevServerMiddleware / handleExecuteAction	Done	DataDog/build-plugins#473, stacked on #471
Single-action execution endpoint (executeActionRemotely is currently a stub)	Blocked	Two real, in-progress paths, not a cold ask: (A) stabilize the existing /api/unstable/actions/execute endpoint (verified directly in actions-api's code), or (B) ddoghq/dd-source#34887's new execute_action MCP tool (draft, Tiffany already collaborating with the author) — see design doc's "Open Dependency" section for the full comparison
Final child_process.fork() vs worker_threads decision	Independent	Expand the native-module compatibility matrix (exercise real native calls, not just require(), across a bigger package set) before locking this in
Security review	Independent	Loop in Jules Denardou / Frederic Hemery per the "Security: Customers Secrets in Terrapin" precedent

Documentation

• Design doc: Local Node execution for High Code Apps backend functions
• Kickoff doc with milestone breakdown
• Related: RFC: Backend Functions, Terrapin Strategy for Backend Functions, APPS-2789.

[tyffical]

Superseded: a team sync (2026-08-04, Terrapin) decided to drop child_process.fork()-based isolation entirely — backend functions will run via a dynamic import() directly inside the Vite dev server's own process instead, not a separate forked child. Same reasoning as on #471 (now also closed): the dev server is already the isolation boundary from production, so a local crash is an acceptable, contained failure — start simple, add isolation back later only if it turns out to actually be needed.

This PR's fork/IPC skeleton and message protocol don't apply to the new in-process model. Likely salvageable for the reimplementation: the $.Actions Proxy's shape (nested-property-path walk → {fqn, inputs, connectionId}), reworked as a direct in-process call instead of an IPC round trip. The native-module compatibility matrix and latency benchmarks from this PR's testing remain useful reference data even though the mechanism they measured is being replaced.

Closing, not deleting the branch, in case anything needs to be referenced later.