SubstreamCancelStrategy
is redundant and confusing considering existence of SupervisionStrategy
attribute
#31394
Labels
1 - triaged
Tickets that are safe to pick up for contributing in terms of likeliness of being accepted
t:stream
When using Akka-Streams its currently documented that if you want to control the behaviour of the stream in the event of an exception you are should use a supervision strategy as part of the attributes, see https://doc.akka.io/docs/akka/current/stream/stream-error.html. While for this works as expected in most cases there is surprising results when you use
Flow
operations thatSplit
the stream (such assplitAfter
).The surprising part comes down to the fact that it completely ignores the configured
SupervisionStrategy
and instead asks for a redundantSubstreamCancelStrategy
parameter. The reason why this is redundant is that in terms of effect/resultSubstreamCancelStrategy.propogate
maps toSupervision.stoppingDecider
andSubstreamCancelStrategy.drain
maps toSupervisionStrategy.resume
/SupervisionStrategy.restart
so In other words there doesn't seem to be any benefit in doing it this way.This is quite surprising because generally speaking if you have a stream represented as a
RunnableGraph
as mentioned before there is an expectation that you would do aAnd strategy propagates to all parts of the stream for all parts of the stream where its possible. Specifically in context of the problem I am dealing with now, i had a custom
SupervisionStrategy
as shown belowIn the case of an exception being thrown in the sink defined in
splitAfter
, since this supervision strategy is ignored and the defaultSubstreamCancelStrategy
isSubstreamCancelStrategy.drain
not only did no exception get logged (so we had no idea what was going on) but it started draining the stream where as the expectation was that it should have cancelled the stream completely and logged the exception (in my case the exception was actually incorrect credentials for S3 which was the passedSink
so rather than immediately stopping the stream instead we spammed S3 with thousands of requests per second as we iterated through a large stream!).Would deprecating the
SubstreamCancelStrategy.propogate
parameter and instead use the existingSupervisionStrategy
from attributes be a reasonable course of action?The text was updated successfully, but these errors were encountered: