title: Concurrently run a Void CompletionStage but ignore result
body: <p>I have two completionStages method calls that each call a remote service if a condition is not met. They are both pretty long running processes and we need to decrease latency. I also do not care for the secondFuture's response. It could return <code>CompletionStage&lt;Void&gt;</code> as I only care if the method runs before we exit the main method. An added complexity is that <code>injectedClass2.serviceCall</code> also throws a really important exception (404 StatusRuntimeException) that needs to be surfaced to the client.</p>
  
  <p>How do I ensure that the first and second future run asynchronously (not dependant on each other) meanwhile the second future surfaces its error codes and exceptions for the client. </p>
  
  <p>Main Method below is my best attempt at this. It works, but I am looking to learn a better implementation that takes advantage of completables/streams,etc. </p>
  
  <pre><code>try {
        .
        .
        .
        CompletionStage&lt;Response&gt; firstFuture;
        CompletionStage&lt;Response&gt; secondFuture = CompletableFuture.completedFuture(Response.default());
        if (condition) {
          firstFuture = legacyImplThing.resolve(param1, param2);
        } else {
          firstFuture =
              injectedClass1.longRunningOp(param1, param2);
          secondFuture = injectedClass2.serviceCall(param1, param2, someOtherData);
        }
  
        final CompletionStage&lt;MainMethodResponse&gt; response =
            CompletableFutures.combine(firstFuture, secondFuture, (a, b) -&gt; a)
                .thenApply(
                    v -&gt; ServiceResponse.newBuilder().setParam(v.toString()).build());
  
        handleResponse(response, responseObserver);
      } catch (Exception e) {
        responseObserver.onError(e);
      }
  </code></pre>
  
  <p>Maybe out of scope, how would one test/check that two completionStages were run concurrently?</p>
  
  <p>EDIT: <code>CompletableFutures.combine()</code> is a third-party library method and not part of the java.util.concurrent package.</p>