Aaron Piotrowski

Can you disable the Spryker error handler and try again? It appears the error handler may not be honoring the current error reporting level and throwing an exception.

How do you bootstrap your initial script? Do you include certain files?

`Worker::enqueue()` returns a promise that can only fail with an instance of `TaskFailureException` or `TaskFailureError`, which both implement `TaskFailureThrowable`. The exception thrown by a `Task` is wrapped in a `TaskFailure`...

Sorry for not addressing this sooner. I can't reproduce this on *nix, so I'll have to get one of the developers with access to a Windows machine to test this....

The obvious solution here is to not use a while loop to accept clients but leave the watcher active and rely in the event loop to invoke the watcher again....

Ah yes, I knew there was a good reason. I guess our own error handler is the correct fix (and probably should be used everywhere we were forced to use...

It appears that you're starting a worker from within another worker, is that the case? How many workers total are you spawning?

Can you please run `composer update` to ensure you're getting `amphp/dns v0.9.14`. That version removed the async hosts file loading which had the dependency on `amphp/parallel`, so at least that...

I think it makes sense to roll support into `CompressionMiddleware`. You'll probably want to split out deflate and brotli into separate handler methods and defer to them to keep it...

Yes, it's certainly nice to have available. I wonder though if in v3 we should default to compression being disabled? Probably doesn't matter too much, as named args make disabling...