Cause and Effect

1. wait_interruptible() in sync.rs returns a boolean value. Therefore any callers of this function cannot identify the difference between a failed compile and an interrupted compile as they both are represented by false.
2. Both failed and interrupted compiles are mapped to an Outcome::Stopped. See server.rs & front.rs.
3. The run_loop interprets Outcome::Stopped as an interrupted compile not a failed compile. It therefore does not clear the change list and so future changes to the same files does not appear to be a change. And I think this is why the recompile does not happen.

Possible Solutions

• Introduce a new enum for wait_interruptible() to return with variants Success, Fail, Stopped.
  Change front.rs and server.rs to map Fail and Stopped to Outcome::Success(Product::None) and Outcome::Stopped respectively.

• Alternatively we could look to reuse the current Outcome enum and maybe add a Failed variant, and return an outcome from wait_interruptible().
  For successful compile we'd return Outcome::Success(Product::None)
  For failed compile we'd return Outcome::Failed
  For interrupted compile we'd return Outcome::Stopped.
  This however would then require the caller of wait_interruptible() (e.g. server.rs) to then check if the binary has changed and then map Outcome::Success(Product::None) to Outcome::Success(Product::Server).

Happy to create a PR if someone could kindly indicate which solution is preferred.

from cargo-leptos.

Thanks @danylaporte for reporting this.

Thanks @phillipbaird for an excellent analysis. I took the liberty to implement your first proposed solution and really hope you don't mind.

from cargo-leptos.