Bean

I have a minimal example which highlights the issue I'm dealing with ```js // example meant to me run within the `/examples` directory const workerpool = require(".."); function main() {...

> Thanks for the clear, sort example. I would indeed expect the worker to be terminated before the `catch` callback is executed. > > I'm not sure if the [`originalTimeout`](https://github.com/josdejong/workerpool/blob/d3e707fd5bcea1d19467e104f70403548f671d7e/src/Pool.js#L149)...

> You may definitely be right! If so, we should find an alternative solution to this wrapper functionality to solve this issue, right? Yes, I have tried things within scope...

@josdejong I have gotten much closer to a working solution. I have gotten the timeout promise to wait for the worker cleanups before fulfilling. However I am still running into...

@josdejong I have committed everything I have done up to this point [here](https://github.com/joshLong145/workerpool/tree/feat/abort-listener-wip). The two tests currently failing `should timeout a task` `should cancel a task` I have also updated...

> Seen the high complexity and hard to debug issues, I indeed think we should do some more thorough refactoring. You may be right that only the task resolver needs...

@josdejong A new MR is up with fixes for the current implementation: https://github.com/josdejong/workerpool/pull/507

@josdejong Since #507 merged in I am thinking we close this out until we can figure out the issues with Promise chaining. The branch with all my refactors is below...

@GwiYeong Thanks for taking the time to write this up. I am doing investigations based on the information provided. Will reach out when I have more.

@GwiYeong @josdejong After changing [abort listener execution](https://github.com/joshLong145/workerpool/blob/85de98559b32e0287a335e52e895517f7fc45193/src/worker.js#L234) to use a race implementation over an `all` implementation. We are now seeing abort handlers resolve if the promise each handler returns fuffils....