I figured it out - I was already using a killswitch in the 'merge cycle retry' stage to close the output end of the MergeHub when the retry-cycle completed, I just needed to call akka.stream.UniqueKillSwitch.abort(Throwable) instead of akka.stream.UniqueKillSwitch.shutdown() when it completed with upstream failure.
On Friday, September 22, 2017 at 10:54:41 AM UTC-7, Bwmat wrote: > > >causing the 'error checker' stage to complete 'successfully' > > Sorry, to be clear, I don't try to swallow the error; is it possible to > detect that an outlet was closed because of an error? > > On Friday, September 22, 2017 at 10:50:27 AM UTC-7, Bwmat wrote: >> >> Oh.. I think I might know what's going on. My graph has a cycle (a >> couple, actually) which is used to implement retrying a request. >> >> I think what's happening is that the 'entry' node into the cycle is >> seeing the failure, propagating it, and then completing. Then, the 'exit' >> node from the cycle sees that the downstream finished, and completes >> itself. This means that it completes 'successfully' _before_ it sees the >> failure from the upstream node. >> >> It seems tricky to make sure all such 'timing' issues are avoided... >> >> Are there some idioms or patterns I can follow to avoid this kind of >> thing? Any suggestions for the current scenario? >> >> To clarify, looking at the (horribly-drawn/lettered) diagram below, the >> exception is being thrown inside of the 'Request Source' stage at the >> upper-left, causing the 'retry-clycle merge' stage to complete, causing the >> 'error checker' stage to complete 'successfully' before the error has >> propagated to its input port. >> >> >> >> On Tuesday, September 19, 2017 at 7:49:53 PM UTC-7, Bwmat wrote: >>> >>> I'm doing a PoC in akka streams, and I just had to track down a case >>> where the mapping functor in an instance of Flow.map() threw an exception. >>> This seems to simply close the stream, but _not_ report it anywhere. Other >>> stages were getting completed implicitly because of it, but the error >>> didn't seem to propagate. >>> >>> The end of my graph was a SinkQueueWithCancel created with Sink.queue(), >>> and I had a thread blocked in a call to >>> sinkQueue.pull().toCompletableFuture().get(). I would have expected the >>> graph's failure to cause this to throw? >>> >>> Also, I had logging set up as described in >>> https://groups.google.com/forum/#!topic/akka-user/rJHu7C8D3KQ , but I >>> didn't see any messages about an uncaught exception, which I would have >>> expected. (makes me think even more that I messed up the configuration >>> somehow?) >>> >>> Thanks, >>> Matthew w. >>> >> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
