I’m writing a piece of my project that works alongside Discord’s API. I’m processing a lot of data and it takes a few second (longer than 5 seconds) to finish processing everything, therefore what I wanted this method to do was to first, acknowledge the slash-command sent to my server and return the correct Discord ACK response, and second, in the background I wanted to process all the data that the user needs and when finally done, I could use Discord’s API to edit the original ACK with the data all processed. So for this, I wrote the following code:

public Mono<InteractionResponse> resolve(Interaction interaction) {
    var raidsAsyncProcessing = processRaidsAsync(interaction)
        .flatMap(response -> discordAPIService
            .editOriginalInteraction(interaction.getToken(), response))
        .subscribeOn(Schedulers.boundedElastic());
    raidsAsyncProcessing.subscribe();

    InteractionResponse ack = InteractionResponse.builder()
        .type(5)
        .data(new InteractionResponseData())
        .build();

    return Mono.just(ack);
  }

My question is, IntelliJ Warnings and pretty much everyone in the reactive space is telling me to not subscribe() in a Reactive context like this, instead to either chain the operators with other reactive operators, or just return the result of the entire reactive chain. Is there a way to write this code piece in a single chain without having to separate the processing part into its own code-block and subscribe to eat separately?

I have tried playing around with both the onPublish() and the onSubscribe() operators trying to understand what kind of outcome would happen if I place them in different parts of the chain of operations. I’ve also tried using a then(Mono.just(ack) in combination with onPublish(Schedulers.BoundedElastic()) but I’m having a hard time grasping and understanding the concept of these operators, and understanding the marble diagrams associated with them.