fix(vitest-pool-workers): ignore sqlite shm and wal files (#5629)

[hansottowirtz]

See https://github.com/cloudflare/workerd/blob/d3b5b16588cc33c930584064995c4a3635d07c28/src/workerd/server/workerd.capnp#L613

Not sure if tests are needed, and how they should be set up, because I do not know how to set up sqlite to generate .sqlite-shm files

What this PR solves / how to test

Fixes #5629

Author has addressed the following

• Tests
  • TODO (before merge)
  • Included
  • Not necessary because:
• Changeset (Changeset guidelines)
  • TODO (before merge)
  • Included
  • Not necessary because: trivial
• Public documentation
  • TODO (before merge)
  • Cloudflare docs PR(s): https://github.com/cloudflare/cloudflare-docs/pull/...
  • Not necessary because: should just work

[changeset-bot]

⚠️ No Changeset found

Latest commit: 297d3b4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mrbbot]

Hey! 👋

Thanks for this PR! I'm not on the team anymore, but I'm not sure about this fix. The reason we fail when we detect non .sqlite files is that these may contain data that we otherwise wouldn't be backing up. The .sqlite-wal file contains SQLite's write-ahead log which may contain things that haven't been written to the main .sqlite file. After each test, we abort all Durable Objects (including internal ones for things like KV and R2 storage), which should "checkpoint" all write-ahead logs into their corresponding .sqlite files and remove them. This error indicates that something was written between test execution and during the process of backing up the database. We fail here because this could result in the incorrect state being restored later on.

Ideally, we wouldn't need to worry about manipulating .sqlite files on disk, and could instead use SQLite SAVEPOINTs to implement the isolated storage stack with nested transactions (#5395). I'd encourage someone on the team to investigate this, as I think it would also significantly improve test performance.

[hansottowirtz]

@mrbbot Thanks a lot for your reply, would ignoring only the .sqlite-shm files be okay?