If restartRunner is spammed, we get EPIPE error

[prisma-labs]

If restartRunner is spammed, we get EPIPE error

[Weakky]

Fixed by restarting the server only when it's fully ready

[Weakky]

Issue breakdown

After investigating, it looks like the issue comes from the SIGTERM signal sent to the child being ignored.

1 ℹ Restarting... schema/Blog.ts
2  graphql-santa:cli:dev:compiler compile start schema/Blog.ts +93ms
3  graphql-santa:watcher runner is still executing, will restart upon its exit +0ms
4  graphql-santa:watcher Disconnecting from child. willTerminate === false so sending sigterm to force runner end +1ms
5  graphql-santa:watcher sending SIGTERM to child 18074 and any of its descendent processes +94ms
6  graphql-santa:watcher sigterm to runner process tree completed +22ms <==== **processes killed**
7  graphql-santa:watcher runner exiting +3ms <= **runner catching that and exiting**
8  graphql-santa:watcher runner did not exit on its own accord +0ms
9  graphql-santa:watcher runner received signal "SIGTERM" which caused this exit +0ms
10  graphql-santa:watcher will spawn runner +0ms
11  graphql-santa:watcher using runner module at /Users/flavian/projects/prisma/graphql-santa-examples/blog/node_modules/graphql-santa/dist/watcher/runner.js +0ms
12  graphql-santa:watcher using child-hook-path module at /var/folders/wt/rlkwn4mn2872qwqjyykz191m0000gn/T/ts-node-dev-hook-13205991653397264.js +0ms
13  graphql-santa:cli:dev:runner starting context type extraction +0ms
14  graphql-santa:compiler finished compiler extension processing with results { contextTypeContributions: [] } +0ms
15  graphql-santa:cli:dev:runner finished context type extraction +960ms
16  graphql-santa:file-watcher file watcher event "change" originating from file/dir schema/Blog.ts +1s
17  graphql-santa:watcher restarting runner because runnerRestarting = false +1s
18 ℹ Restarting... schema/Blog.ts
19  graphql-santa:cli:dev:compiler compile start schema/Blog.ts +1s
20  graphql-santa:watcher runner is still executing, will restart upon its exit +0ms
21  graphql-santa:watcher Disconnecting from child. willTerminate === false so sending sigterm to force runner end +0ms
22  graphql-santa:watcher sending SIGTERM to child 18076 and any of its descendent processes +1s
23  graphql-santa:watcher sigterm to runner process tree completed +21ms <==== **processes killed**
24  graphql-santa:plugin-manager loading runtime of plugin prisma +0ms <==== **runner continues to run ....**
25  graphql-santa:plugin:prisma Running runtime... +0ms
26  graphql-santa:schema finding modules... +0ms

We can compare a successful run on line 6 and 7

6  graphql-santa:watcher sigterm to runner process tree completed +22ms <==== **processes killed**
7  graphql-santa:watcher runner exiting +3ms <= **runner catching that and exiting**

with a run that eventually ends up with an EPIPE error on line 23 and 24.

23  graphql-santa:watcher sigterm to runner process tree completed +21ms <==== **processes killed**
24  graphql-santa:plugin-manager loading runtime of plugin prisma +0ms <==== **runner 

☝️ On line 23, a sigterm is sent to the child, yet on line 24, we see it continues its execution, resulting quickly after in an EPIPE error

Sending a SIGKILL to the child instead does fix the problem, but sending SIGKILL is dangerous and cannot be caught by the child process and might leave zombie processes.

Next steps

1. Investigate why SIGTERM is sometimes ignored (might actually be all the time).
   • I think one reason might be that our code is run using new Script().runInThisContext() while ts-node-dev uses a simple require()