Open warner opened 2 months ago
Note that this test file has two parts, which must be run together, and serially: the first sets up the conditions for the second. There's a comment that points out this is probably a bad idea, and that the test should be rewritten somehow.
The two parts share a RAM-based swingstore DB (using initSwingStore()
without an argument), via a test.before()
hook. That is easy enough to move into a single test, tearing down the first kernel and then building a second around the same DB.
I saw an intermittent test failure in
packages/SwingSet/test/device-plugin/device.test.js
that is worth tracking down the root cause of. It appeared in a CI run of PR #10033 , which didn't change any of the files involved (it just added some unused classification tools tomisc-tools/
), so it should not have been able to trigger a failure. I haven't seen this failure mode before, and running the test locally a few dozen times didn't reproduce it, so it's that worst kind of intermittent where it only happens on someone else's computer.This is the job named
test-swingset (20.x, 0, 5)
, and the step namedyarn test (SwingSet)
, rather than the step namedyarn test (SwingSet XS Worker)
. That means we'll be using a local (Node.js) worker, unless the test overrides that choice (and this one doesn't). I don't think that is likely to make a difference, because devices are always co-resident with the kernel, regardless of how vats are run.Because the CI records will probably get deleted, here's a copy: