flaky(test): computer-use maka-cu-service teardown races temp-root removal (ENOTEMPTY) #3290

Summary

packages/computer-use/dist/__tests__/maka-cu-service.test.js fails intermittently on the Linux test lane (Run affected standard workspace tests) with a temp-directory cleanup race:

✖ /home/runner/work/maka/maka/packages/computer-use/dist/__tests__/maka-cu-service.test.js (14.7ms)
[Error: ENOTEMPTY: directory not empty, rmdir '/tmp/maka-test-computer-use-9VpvvT/maka-cu-service-test-fYcMJy']
  { errno: -39, code: 'ENOTEMPTY', syscall: 'rmdir', path: '…' }
[computer-use] failed with code 1

All 971 tests in the affected run otherwise passed (fail 0 in the desktop workspace summary of the same run); the suite fails only in its cleanup.

Evidence

• 2026-08-20 ~05:56 UTC, PR feat(win): Abort-path installer rollback with backup retention #3265 (installer rollback — does not touch packages/computer-use at all): run 32337361618, job test, step "Run affected standard workspace tests".

Analysis

ENOTEMPTY on rmdir during teardown is the same defect family as the Windows EBUSY cleanup failures documented in docs/windows-support.md ("Stores, owners, and leases must close deterministically before their temporary root is removed") — a child process or open handle created by the test is still writing into the temp root when the recursive removal runs, or the removal races a concurrently-created file. On Linux this surfaces as ENOTEMPTY instead of EBUSY.

Likely fixes, for the owning team to judge:

• await/settle whatever the service spawns (or its log/artifact writers) before the temp root is removed, mirroring the deterministic-close work done for the storage suites in Phase 1;
• or use fs.rm(root, { recursive: true, force: true, maxRetries: N, retryDelay: … }) in the test teardown, which the release verifier scripts already standardize on — though retries paper over a still-running writer, so the deterministic settle is the better first choice.

Friction note

Since the Apache migration gh run rerun requires admin rights, so a contributor hit by this flake can only recover by pushing an empty commit — which cancels in-flight lanes for the ref and re-triggers all review bots.