Skip to content

[APPS-2792] Add: local-execution resilience tests (Milestone 7) - #492

Draft
tyffical wants to merge 1 commit into
tiffany.trinh/apps-2792-wire-into-dev-serverfrom
tiffany.trinh/apps-2792-local-execution-resilience-tests
Draft

[APPS-2792] Add: local-execution resilience tests (Milestone 7)#492
tyffical wants to merge 1 commit into
tiffany.trinh/apps-2792-wire-into-dev-serverfrom
tiffany.trinh/apps-2792-local-execution-resilience-tests

Conversation

@tyffical

Copy link
Copy Markdown
Contributor

Motivation

  • Milestone 7 in the Local Node Execution Kickoff doc — renamed/descoped from "Chaos-engineering resilience testing" since domains/chaos-engineering targets Datadog-owned Kubernetes clusters, a mismatch for this in-process, customer-dev-server model.
  • Two targeted resilience checks, not fixes: empirically confirm the actual failure modes of the RFC's "no process isolation" decision, rather than leave them as assumed-but-unverified.

Changes

What changedFile
New test confirming a synchronous CPU-bound loop starves the event loop, so the current Promise.race timeout never gets a chance to fire — it can only settle once the loop finishes on its own.local-execution.resilience.test.ts
New test (via a real child process, since process.exit() can't safely run inside this same Jest process) confirming process.exit() inside the customer function terminates the whole process immediately, bypassing try/finally cleanup entirely.local-execution.resilience.test.ts

The third Milestone 7 task ("the queue survives a rejected execution and keeps running") was already covered by an existing test in local-execution.test.ts, per the Kickoff doc's own checklist.

QA Instructions

yarn workspace @dd/tests test:unit packages/plugins/apps/src/vite/local-execution.resilience.test.ts
# Expected: 2 passed ✅ VERIFIED
yarn workspace @dd/tests test:unit packages/plugins/apps
# Expected: 25 suites / 324 tests passed ✅ VERIFIED
yarn workspace @dd/apps-plugin run typecheck
# Expected: clean exit ✅ VERIFIED

Blast Radius

  • Test-only change, no production code touched. Zero effect on shipping behavior.
  • Risk: none.

Out of Scope / Follow-ups

ItemStatusNext step
Whether to pursue real process/thread isolation (e.g. pooled worker_threads) to close the confirmed sync-hang and process.exit() gapsdeferredThese tests exist specifically to inform that decision with real data rather than speculation — a follow-up design discussion, not blocking this PR.

Documentation

…des (Milestone 7)
Two targeted resilience checks, not fixes — Milestone 7 in the Kickoff doc
exists to empirically confirm the actual failure modes of running backend
functions in-process (no child process/thread isolation) before deciding
whether closing them is worth the cost the RFC already weighed against
fork()-based isolation.
Confirmed: a synchronous CPU-bound loop starves the event loop entirely, so
the current Promise.race timeout never gets a chance to fire — it can only
settle once the loop finishes on its own. Confirmed via a real child
process: process.exit() inside the customer function terminates the whole
process immediately, bypassing try/finally cleanup entirely — no JS-level
exception handling in this design can intercept it, so this takes the whole
dev server down, not just its own execution.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@tyffical