Vitestのゾンビプロセス対策
vitestを何も設定せずに実行するとwatchモードになるのが原因ではないかと考えた。
実際、以下のような記事もあった。
某Slackコミュニティでも当該現象の解決方法として同様の解決方法が挙げられていた。
vitest runまたはvitest --runを実行する
vitest.config.tsを以下のように設定する
code:vitest.config.ts
export default defineConfig({
test: {
watch: false,
},
});
しかし、これらのの方法でコマンドをワンショットにするだけでは効果がなく、この設定私の環境では問題が何度も起きた。
そもそもこの問題は、vitestがテストを並列実行するためにプロセスforkを使用していることが関連していると思われる
code:txt
node@1def37443e2d:/workspace$ ps aux | grep vitest
node 15248 114 10.4 14835164 3404920 ? Rl 08:46 3:03 node (vitest 2)
node 15255 112 10.4 4339064 3389236 ? Rl 08:46 2:59 node (vitest 4)
node 15262 110 9.9 14686244 3252056 ? Rl 08:46 2:56 node (vitest 6)
node 15290 108 10.0 14708772 3272780 ? Rl 08:46 2:52 node (vitest 9)
node 15309 109 10.3 4595184 3382668 ? Rl 08:46 2:55 node (vitest 10)
node 15659 110 9.4 4035896 3084124 ? Rl 08:46 2:56 node (vitest 13)
コーディングエージェント経由でvitestを実行するとなぜforkされたプロセスが残ってしまうのかの調査はできていない
しかし、プロセスが残るのが原因であれば、マルチスレッドによる並列実行に変更すれば問題は解消されるのではないかと考えた。
code:vitest.config.ts
export default defineConfig({
test: {
pool: 'threads',
},
});
この方法で問題が解消された。
Some libraries written in native languages, such as Prisma, bcrypt and canvas, have problems when running in multiple threads and run into segfaults.
とあるので、万能な解決策ではない。
threadsが使えないときにはforkのまま単一のプロセスを使うように設定するのが良いだろう。