search

WiseLibs / better-sqlite3

The fastest and simplest library for SQLite3 in Node.js.
MIT License
5.37k stars 394 forks source link

Adjust test to pass with slower GHA macOS box #1051

Closed mceachen closed 1 year ago

mceachen commented 1 year ago

This should allow the upgrade to 3.43 to pass:

Failure from GHA:

  1) new Database()
       should accept the "timeout" option:
     AssertionError: expected 1468 to be close to 1000 +/- 200
      at testTimeout (test/10.database.open.js:101:31)
      at Context.<anonymous> (test/10.database.open.js:109:3)
      at process.processImmediate (node:internal/timers:476:21)

https://github.com/WiseLibs/better-sqlite3/actions/runs/5965363532/job/16186656443?pr=1050

mceachen commented 1 year ago

@JoshuaWise this is blocking the upgrade to SQLite 3.43.

JoshuaWise commented 1 year ago

Closing this in favor of https://github.com/WiseLibs/better-sqlite3/commit/6ee3399932c73c0f34d1b2e604d50b44a4e94f6f. This is also related to https://github.com/WiseLibs/better-sqlite3/issues/597. I've enabled the long-overdue HAVE_USLEEP=1 compile-time option, which allows the timeout option to be more granular. It turns out that when enabling HAVE_USLEEP=1, the CLI builds for macos-latest take much longer than expected. After investigating, the test times were always 2x-3x the specified timeout. For example, if the timeout was 200ms, it would take 400-600ms; if the timeout was 1000ms, it would take 2000-3000ms. The behavior is quite mysterious, but I can't reproduce it on my local MacOS machine, so I assume it could have something to do with GitHub Actions de-prioritizing virtual machines that are idle. Anyways, it works as intended on all real machines I test it on, so I don't think it's a big deal. In any case, timeouts are never exact in programming—they are always best-effort/minimum times anyways.