Asynchronously assembling a complex object

As for me it looks fine except one thing. You have already completed Task in .ContinueWith block, thus you may use .Result then instead of await and avoid redundant async State Machine.

By the way, if you're using async/await, probably there's no continuations needed.

Consider this continuations-free implementation of 1st Task.WhenAll() job.

public async Task<Account> Retrieve(AccountId input1, DateTime input2)
{
    var account = new Account();

    // probably try-catch wrapper maybe useful here as replacement of !mapTask.IsCompletedSuccessfully
    await Task.WhenAll((Func<Task>)(async () =>
    {
        T_AccountMapper map = await _tAccountMapperRepo.Retrieve(input1);
        // continuation:
        AccountMap accountMap = new AccountMap(map.AccountId, map.Login, map.Namespace);
        account.SetAccountMap(accountMap);
    })
    //, (Func<Task>)(async() => {...})
    );

    return account;
}

As you can see, TranslateAccountMap method isn't needed anymore.

Finally, it's up to you.

P.S. Here's a useful link.

Here I've two alternative versions of Bryan Boettcher revised code.

In his version there are 4 ETL functions and they are running concurrently.

In my solutions only the Extract part is running concurrently. The Transformation and Load parts are executed sequentially.

Alternative #1

Please bear in mind that I had to use some made up type names (like: AccountType, PaymentRedirection) because I could not tell the exact types based on the provided code.

public async Task<Account> RetrieveAsync(AccountId accountId, DateTime dateTime)
{
    //Extract
    var accountTypeJob = RetrieveAccountType(accountId);
    var paymentRedirectionJob = RetrievePaymentRedirection(accountId, dateTime);
    var accountMapJob = RetrieveAccountMap(accountId);
    var parentAccountMapJob = RetrieveAccountMapForParent(accountId, dateTime);

    //Transform
    var accountType = await accountTypeJob;
    var convertedAccountType = _accountTypeConverter.Convert(accountType);

    var paymentRedirection = await paymentRedirectionJob;
    var convertedPaymentRedirection = _paymentRedirectionConverter.Convert(paymentRedirection);

    var accountMap = await accountMapJob;
    var convertedAccountMap = _accountMapConverter.Convert(accountMap);

    var parentAccountMap = await parentAccountMapJob;
    var convertedParentAccountMap = _accountMapConverter.Convert(parentAccountMap);

    //Load
    var account = new Account();
    account.SetAccountType(convertedAccountType);
    account.ChangePayerToAccount(convertedPaymentRedirection);
    account.SetAccountMap(convertedAccountMap);
    account.MoveAccountToNewParentAccountMap(convertedParentAccountMap);
    return account;
}

private async Task<AccountType> RetrieveAccountType(AccountId accountId)
{
    var baseAccount = await _tAccountRepo.RetrieveAsync(accountId);
    return await _tAccountTypeRepo.RetrieveAsync(baseAccount.TypeId);
}

private async Task<AccountMap> RetrieveAccountMapForParent(AccountId accountId, DateTime dateTime)
{
    var accountAncestor = await _tAccountAncestorRepo.RetrieveAsync(accountId, dateTime);
    return await _tAccountMapperRepo.RetrieveAsync(accountAncestor.DescendentId);
}

private async Task<PaymentRedirection> RetrievePaymentRedirection(AccountId accountId, DateTime dateTime)
{
    return await _tPaymentRedirectionRepo.RetrieveAsync(accountId, dateTime);
}

private async Task<AccountMap> RetrieveAccountMap(AccountId accountId)
{
    return await _tAccountMapperRepo.RetrieveAsync(accountId);
}

As you can see I have 4 RetrieveXYZ functions and these are responsible for loading data. I suppose these are I/O operations, so they are not CPU-bound (concurrency is not limited by the available cores).

During the Extract phase I start all of the Tasks, so there is no need to explicitly call the Task.WhenAll In the Transform phase I access the retrieved data via the await keywords.

Alternative #2

With a simple helper function we can make the RetrieveAsync function neater and more concise.

public static class TaskExtensions
{
    public static async Task<(T1, T2, T3, T4)> WhenAll<T1, T2, T3, T4>(Task<T1> t1, Task<T2> t2, Task<T3> t3, Task<T4> t4)
    {
        return (await t1, await t2, await t3, await t4);
    }
}

By taking advantage of this helper method the new version of the RetrieveAsync would look like this:

public async Task<Account> RetrieveAsync(AccountId accountId, DateTime dateTime)
{
    //Extract
    var (accountType, paymentRedirection, accountMap, parentAccountMap) = await TaskExtensions.WhenAll(
        RetrieveAccountType(accountId), RetrievePaymentRedirection(accountId, dateTime),
        RetrieveAccountMap(accountId), RetrieveAccountMapForParent(accountId, dateTime));

    //Transform
    var convertedAccountType = _accountTypeConverter.Convert(accountType);
    var convertedPaymentRedirection = _paymentRedirectionConverter.Convert(paymentRedirection);
    var convertedAccountMap = _accountMapConverter.Convert(accountMap);
    var convertedParentAccountMap = _accountMapConverter.Convert(parentAccountMap);

    //Load
    var account = new Account();
    account.SetAccountType(convertedAccountType);
    account.ChangePayerToAccount(convertedPaymentRedirection);
    account.SetAccountMap(convertedAccountMap);
    account.MoveAccountToNewParentAccountMap(convertedParentAccountMap);
    return account;
}

Advantages

• Only the I/O bound operations are running concurrently
  • Each helper function has single responsibility
  • The top-level function acts as a coordinator
• There is no shared resource, so we don't have to worry that much about thread-safety

Disadvantages

• If the Transform and/or Load parts are I/O bound as well then this approach would be slower
• It is not relying on the built-in Task.WhenAll rather than it relies on the ValueTuple and C# 7's Deconstruction capabilities, so it can't be used in older .NET Framework versions.