On the client:
a. User runs process-compose down
b. Client makes request to /project/stop
On the server:
a. ProjectRunner.ShutDownProject() stops all processes
b. cmd.runProject() stops blocking
c. Exits before PcApi.ShutDownProject has written the response
On the client:
a. Gets EOF reading the response because the server has gone away
I can't think of a way to reproduce this in a test, except for something
convoluted like creating a custom client that introduces a delay in
reading the response.
It can be "manually" simulated by adding a small delay here though:
bash-5.2$ go run src/main.go up --config services.yaml --tui=false &
[1] 8171
bash-5.2$ go run src/main.go down
24-07-12 15:38:40.332 FTL failed to stop project error="Post \"http://localhost:8080/project/stop\": EOF"
exit status 1
[1]+ Done go run src/main.go up --config services.yaml --tui=false
After this change:
bash-5.2$ go run src/main.go up --config services.yaml --tui=false &
[1] 8432
bash-5.2$ go run src/main.go down
To prevent a race condition seen in https://github.com/F1bonacc1/process-compose/issues/197:
process-compose down
b. Client makes request to/project/stop
ProjectRunner.ShutDownProject()
stops all processes b.cmd.runProject()
stops blocking c. Exits beforePcApi.ShutDownProject
has written the responseEOF
reading the response because the server has gone awayI can't think of a way to reproduce this in a test, except for something convoluted like creating a custom client that introduces a delay in reading the response.
It can be "manually" simulated by adding a small delay here though:
And using this config:
Before this change:
After this change: