Mingan

Are you restarting the goworker application? We see this behaviour when the application is hard-stopped and doesn't have time to cleanup the records in Redis (`workers` and `worker:[node]` keys).

Yeah, the problem is to figure out a safe mechanism to do so and keep it compatible with the Resque gem.

If it's the same issue we have experienced, there are extra values in the set of workers and the dead workers appear to still be working in the UI (there...

This bothers me as well about goworker :clap:. Have you considered [errors](https://github.com/pkg/errors) library? I assumed it was the de facto standard for this problem and [GitHub stars](https://golanglibs.com/search?q=errors&sort=top) seem to agree.

@rohit4813 The current implementation listens for few signals and if it receives them, it stops enqueuing new jobs but lets the running jobs finish. I'm not sure I understand exactly...

@rohit4813 Our use case just creates breakpoints in long-running jobs so that when we need to restart the process, we don't have to wait (tens of) minutes for the whole...

I'd like to clarify that for this to work, you need to be on node-test-runner 0.18.9 or newer which [doesn't stop when it can't install dependencies](https://github.com/rtfeldman/node-test-runner/pull/200).

Thank you for the tip. An uncharitable reading of your comment would be _the intended behaviour is chaos and confusion_. I assume you don't mean it but closing the issue...

I'm not a Romanian speaker but I added Czech.

I'm in the same boat, running [email protected]. I have no sync running but my path setup is atypical (because of Webpacker) but I have some private packages installed using [elm-install](https://github.com/gdotdesign/elm-github-install)....