Akka: UnzipWith documentation incorrectly states that it cancels eagerly

Created on 4 Dec 2018 · 3Comments · Source: akka/akka

UnzipWith (both javadsl and scaladsl) states that it cancels when any downstream cancels. However, the actual implementation cancels only when the _last_ downstream cancels.

1 - triaged help wanted docs stream

Source

baltiyskiy

👍1

Most helpful comment

It also affects Unzip. Is it really just a documentation issue? Or actually a bug, and implementation needs to be adjusted?

For sure it is currently inconsistent with other FanOutShape implementations (Broadcast, Balance, Partition), maybe it makes sense to align with them by adding an eagerCancel parameter?

SupraFii on 25 Dec 2018

👍2

All 3 comments

That's a valuable clarification! Would you be interested in proposing a PR to fix the docs?

raboof on 4 Dec 2018

It also affects Unzip. Is it really just a documentation issue? Or actually a bug, and implementation needs to be adjusted?

For sure it is currently inconsistent with other FanOutShape implementations (Broadcast, Balance, Partition), maybe it makes sense to align with them by adding an eagerCancel parameter?

SupraFii on 25 Dec 2018

👍2

We also fell into this trap, I wonder what the initial rationale was to not have Unzip cancel. There is a specific test case for this.

https://github.com/akka/akka/blob/6bf20f4117a8c27f8bd412228424caafe76a89eb/akka-stream-tests/src/test/scala/akka/stream/scaladsl/GraphUnzipSpec.scala#L53

update
There was the idea to have a eagerCancel option but it was not implemented
https://github.com/akka/akka/issues/15396

Workaround is to use a Broadcast(2) and do a map on each of the outputs