[SERVER-52887] Make a proper way to "detach" a future chain Created: 16/Nov/20  Updated: 28/Feb/23

Status: Open
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Participants:

 Description   

When users write futures code, if the user saves a future in a local variable, they tend to write code like this:

    auto future = getFuture()
        .then([] {
            // Handle success
        })
        .onError([](Status s) {
            // Handle error
        });

This is the proper way to write that code. If, however, they want to ignore the result of that future chain, they might instead write:

    getFuture()
        .then([] {
            // Handle success
        })
        .onError([](Status s) {
            // Handle error
        })
        .getAsync([](auto) {});

This is correct semantically, but unfortunately, in the case where getFuture returns an ExecutorFuture, this getAsync call will result in an extra call to schedule on the executor even though the lambda is empty and does nothing.

In the past, such code is met with comments to do

    getFuture()
        .getAsync([](StatusWith<T> swVal) {
            if (swVal.isOK()) {
                // Handle success
            } else {
                // Handle error
            }
        });

In my view this is unfortunate given how it differs from the way that we typically formulate future chains, as in the first example.

It has also been deemed inappropriate to simply do a void cast:

    (void)getFuture()
        .then([] {
            // Handle success
        })
        .onError([](Status s) {
            // Handle error
        });

We should come up with an idiomatic way to handle this scenario and allow the API to be consistent with normal future chain usage.



 Comments   
Comment by Lauren Lewis (Inactive) [ 18/Mar/22 ]

We haven’t heard back from you for some time, so we're going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Generated at Thu Feb 08 05:29:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.