Stephen Compall b35c9fcb3d slow down trigger on RESOURCE_EXHAUSTED failures (#7820) ... * restate the submit stage as a Flow and derived Sink * take submit out of the trigger-to-submit flow * type for the failures produced directly by command submission * directly connect the msgSource failure queue to the submitter output * parens * slow down submission as we exceed max parallel submissions * restricting alterF so it will be usable with ConcurrentMap * disable buffer for the delay * split out the delay function * drafting a retry loop * degenerate test for retry loop, factoring the forAllFuture utility * map input to retrying properly * make retrying accessible to tests * test happy path and fix off-by-one * further tests for retrying * reveal that elements can get lost * more determinism in test * let failures block further elements from being attempted - Previously failures would go into a separate queue, where they awaited expiry of their delay and further initial upstream elements were given their first tries. However, closing the upstream could mean that queue was dropped, and detecting that situation is not trivial. So, instead, we don't use a separate queue. * plug retrying into the trigger submission flow * no changelog CHANGELOG_BEGIN CHANGELOG_END * remove throttle; pendingCommandIds may leak * report random parameter on failure * revert comment about throttling * explanation for fail in the error queue - suggested by @cocreature; thanks		2020-11-10 21:36:48 +00:00
..
src/main	slow down trigger on RESOURCE_EXHAUSTED failures (#7820)	2020-11-10 21:36:48 +00:00
BUILD.bazel	trigger request submissions backpressure the transaction stream (#7753)	2020-10-23 10:00:38 -04:00