Skip to content

Windows hardware-session launcher: prove grandchild (engine) kill in the force-kill test; minor hardening follow-ups #75

Description

@rohanpandula

Follow-ups from the adversarial review of #74 (merged as-is; verdict was approve, no P0/P1).

P2 — grandchild kill is not runtime-proven. The force-kill case in ports/tauri/packaging/windows/tests/test-hardware-session-launcher.ps1 asserts only the direct child app PID disappears after $forcedLauncher.Kill(); the fake runtime's RunApp() spawns nothing, so the Job Object's descendant-kill (the engine grandchild) is unexercised. Residual risk is bounded (kernel job inheritance + the dual env/latch gate, and the guardian still removes the latch half), but a future regression adding CREATE_BREAKAWAY_FROM_JOB to the engine spawn would go undetected. Smallest fix: have the fake app spawn a fake engine child and assert its PID is absent after the forced kill. Note the PowerShell 5.1 suite is not run by CI (only the .sh twin is), so this needs authoring/validation on a real Windows host.

P3s (optional):

  • Add one fully-clean-parent-env launch case to the PS suite (every current case runs with a polluted parent; production norm is clean).
  • scanstudio-hardware-session-latch.sh: use ${process_argument##*/} for the scanstudio_bridge.cli orphan match too, so path-qualified forms are covered.
  • Consider a longer/retried guardian-ready window than 10 s (cold machines can fail closed pre-arming; safe but flaky).
  • ContactSheet not-enabled guidance names the Start-menu shortcut but not the portable .cmd equivalent.
  • build-and-verify.ps1 preflight: also check for a lingering scanstudio-engine* process.
  • Latch helper: SIGKILL'd runs leave stale .hw-motion-* temp files (hygiene only).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions