We realised after a long conversation that Completes<T> right now has an important issue that needs to be tackled: a Completes<T> pipeline can be run during the composition fase, because it runs potentially in different threads.

Our new proposal is to actually rework how Completes<T> works so it can be simplified, more efficient and easier to change. The design decisions that we want to take:

• Completes<T> composition will only be done in a single thread.
• Completes<T> execution will be lazy, it will be only run when there is an outcome and it's marked as ready.
• Completes<T> will be executed in a threadpool only if it's marked as ready and has an outcome.
• Completes<T> will separate two responsibilities: who is sending the outcome to the chain, and how the chain processes the outcome. For example, you can have a SingleSource<T> that will only emit a single outcome to the whole chain, and you can have also a RepeatableSource<T> that can emit up to N elements. We can build more sources from CompletableFuture<T> and other async components.
• Timeouts will act as gateways. We are not measuring the time we spend processing a step in the chain, but the deadline from an outcome to pass through the timeout gateway. So it will measure the time between outcomes.

Opinions and feedback are really appreciated.

It's also a good opportunity to work on the following issues and solve them:

• Support Completes<T> and CompletableFuture<T> In One Pipeline #15
• Support for composition of Completes #14
• Completes.recoverFrom() should support a handler that returns a Completes<Y> not just Y #13
• BasicCompletes Must Handle Latent Registration of recoverFrom(Exception) #12