Strategy that treats cancelStage in different ways depending on the cause that was given to the cancellation.
If the cause was a regular, active cancellation (SubscriptionWithCancelException.NoMoreElementsNeeded), the stage receiving this cancellation is completed regularly.
If another cause was given, this is treated as an error and the behavior is the same as with failStage.
So it seems it shouldn’t raise this error to user level. What am I missing? I have tried with 2.6.10, 2.6.15 etc after seeing this akka/akka#30071 but it doesn’t help in my case.
It always runs fine on my local but fails with the above exception on production (in AWS + k8s). With the same input, it fails at different time. Sometime it fails at 90% stream completion, sometimes 99%.
Am I missing something? How should I handle this error?
That stream itself shouldn’t lead to a cancellation, Sink.ignore consumes until it sees the end of the stream, and none of the other used operators shown cancels upstream. This should mean it is either something in your flow or an issue in the S3.download internals.
Where/how are you observing the cancellation exception, logged by internals or by your own code (a custom graph stage for example)?
@joroKr21 Hi, yes i did. Now i download large file split to small chunks (1mb) and download those one by one. This small substream is now materialized, which “fixed” the error entirely. I tried not materializing them and retry downloading, but it failed too much. So materializing it was best option.
Getting this error and it only occurs in github actions which is likely due to it having a much faster network connection. As you said increasing it to 1 second help.
Does it make sense to increase the default akka.http.client.stream-cancellation-delay to 1 second since that appears to be a lot more reasonable?