Unable to delete test-sqlite-database-sync tempfiles on win11_vs2022-arm64 runners

[thisalihassan]

Test

2,win11-arm64-COMPILED_BY-vs2022_clang-arm64

test-sqlite-database-sync

Platform

No response

Console output

test-sqlite-database-sync
parallel
6	0.47 sec	
Error Details
fail (1)
Stack Trace

---
duration_ms: 479.999
exitcode: 1
severity: fail
stack: |-
  Can't clean tmpdir: d:\workspace\node-test-binary-windows-js-suites\node\test\.tmp.872
  Files blocking: [
    'database-1.db',  'database-10.db',
    'database-11.db', 'database-12.db',
    'database-13.db', 'database-15.db',
    'database-17.db', 'database-18.db',
    'database-19.db', 'database-2.db',
    'database-21.db', 'database-24.db',
    'database-25.db', 'database-26.db',
    'database-27.db', 'database-3.db',
    'database-4.db',  'database-5.db',
    'database-6.db',  'database-7.db',
    'database-8.db',  'database-9.db'
  ]

  d:\workspace\node-test-binary-windows-js-suites\node\test\common\tmpdir.js:80
      throw e;
      ^

  Error: EPERM, Permission denied: \\?\d:\workspace\node-test-binary-windows-js-suites\node\test\.tmp.872 '\\?\d:\workspace\node-test-binary-windows-js-suites\node\test\.tmp.872'
      at Object.rmSync (node:fs:1206:18)
      at rmSync (d:\workspace\node-test-binary-windows-js-suites\node\test\common\tmpdir.js:31:8)
      at onexit (d:\workspace\node-test-binary-windows-js-suites\node\test\common\tmpdir.js:65:5)
      at process.<anonymous> (d:\workspace\node-test-binary-windows-js-suites\node\test\common\tmpdir.js:54:14)
      at process.emit (node:events:521:24) {
    errno: 1,
    code: 'EPERM',
    path: '\\\\?\\d:\\workspace\\node-test-binary-windows-js-suites\\node\\test\\.tmp.872',
    syscall: 'rm'
  }

  Node.js v26.0.0-pre
...

Build links

Additional information

No response

[thisalihassan]

@aduh95 @Renegade334 this seems to be a Windows ARM64 cleanup flake in test-sqlite-database-sync

The failure is in test/common/tmpdir.js at exit and it looks like the test is relying on GC/finalization for some file-backed DatabaseSync instances instead of closing/disposing them deterministically

[Renegade334]

Hmmm, it looked like a persistent issue on a single runner, but now seems to be a) intermittent and b) present on a second node. The only thing I can think is some kind of timing issue, as the current behaviour relies on the database handle being GC'd prior to the process exit hook.