Skip to content

JS harness: a case timeout abandons the attempt — it cannot cancel it, and the wedged case keeps running in-process #81

Description

@lann

Migrated from polymorph-components/polymorph-webrtc-datachannels#128, where it was filed against the jco-era in-process adapters. Those are gone (webrtc's #135 moved the loop here, its #151 deleted the jco children), but the defect transferred rather than resolved: it now lives in the shared JS harness loop.

On case timeout, the harness loop (js/viewer/harness.mjs, runCases) records limit-exceeded and moves on — the timed-out attempt is abandoned, not cancelled. JS offers no preemption, so whatever the case was awaiting keeps executing in the same Deno process (deltic-deno children) or browser page (deltic-browser children): pending network activity, timers, and event handlers from the wedged attempt can contaminate every subsequent case in the run.

freshCases (default on) isolates per-case suite instances, but not the abandoned attempt's side effects — e.g. a wedged peer connection keeps its handlers and its network activity.

Options recorded on the original issue:

  • per-case child process at the driver layer — full isolation, pays a process spawn per case;
  • worker-level termination: run cases in a worker the harness can kill on timeout (page workers already exist on the browser leg);
  • at minimum, document the contamination hazard on the timeout path so suite authors know a limit-exceeded verdict may poison later cases in the same run.

Related: #47's --hard-timeout escalation ladder — a kill tier there would subsume this for process-per-run drivers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    runnerComponents or hosts that execute suites

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions