Watch mode not waiting for running task to properly terminate

[struckchure]

Description

I tried using taskfile to automatically reload a Go project using echo, and also tried it with NestJS. The reload is being triggered, but I always get an error that translates to "the current port I'm trying to start my app on is being used" (by the previously terminated process), my guess here is taskfile didn't wait for the process to be fully terminated before starting a new one or maybe I'm missing an extra configuration.

Code Sample

// main.go

package internals

import "github.com/labstack/echo/v4"

func main() {
    e := echo.New()
    e.Start(":8000")
}

Version

3

Operating system

MacBook M1 Pro 2020

Experiments Enabled

No response

Example Taskfile

version: 3

tasks:
  dev:
    watch: true
    sources:
      - '**/*.go'
    cmd: go run .

[trulede]

@struckchure hi, Task will only run the watch task again so you need to take care of any lifecycle details.

Such as:

• killing the echo server before starting it (since currently .. its still running)
• run your echo server in the background

And perhaps even adding a retry loop for your e.Start() if its still a little flaky.

[struckchure]

@struckchure hi, Task will only run the watch task again so you need to take care of any lifecycle details.

Such as:

* killing the echo server before starting it (since currently .. its still running)

* run your echo server in the background

And perhaps even adding a retry loop for your e.Start() if its still a little flaky.

I understand, thank you so much.

I just saw the warning from the doc concerning this as well. After I tried looking into the watch.go file in the codebase, it just didn't add up to me as to why it wasn't working. I couldn't fix it as well, but if you can identify the problem, I'd like to attempt a fix still

[trulede]

Its WithCancel(). Issue #160.

[trulede]

@struckchure I think the last comment from 160 is probably your best path to follow.

- kill $(lsof -ti :9090) 2>/dev/null || true

There is a slight race condition, it might be possible to signal a process (of the context) before cancelling the context; which is what the above does. Or find a more reliable mechanism. I think signal(s) and watching a process ID (until its gone) is probably going to be most reliable. You would have to figure out how to get the PID - you might get some ideas here: https://github.com/search?q=repo%3Amvdan%2Fsh%20pid&type=code