How to communicate back the partial errors to the client (Anoop)

Issue #32 open
Nat Sakimura created an issue

While implementing DDA, Anoop et al. came across a new use case.

Sometimes, when banks are returning data, some of the sub-system may not be available temporarily and results in partial results.

For example, the Bank's credit card system may be on maintenance mode and the bank may not be able to return data on credit card while it can return everything else. It is just a temporary error.

We have not defined anything on this. Bank needs to communicate it back to the client. e.g., yesterday I returned 5 accounts but today I am returning only 3. However do not delete the 2 as it is only temporarily unavailable. When we come back, I might be able to return them.

Comments (10)

  1. Sascha Preibisch

    For me it does not sound like a partial error. Nothing went wrong. The response should have a 200-isch HTTP status and for that reason error codes are not applicable here. The response should include a note that some data is not available right now.

  2. Nat Sakimura reporter

    OK. It may not be an error, but it needs to communicate the fact in any case. How would you propose to do so? One possible way is to include some metadata in the JSON like:

    "_meta":{
        "_result_type":"partial; some accounts under maintenance";
    }
    

    etc.

    Do you have any suggestions?

  3. Anoop Saxena

    Sascha is right .. You will get HTTP 200 and possible few successful accounts. Maybe one of them could have temporary error. The recommendation we are making

    <DepositAccount> <AccountId>1</AccountId> <Error> <Code>700</Code> <Message>Account information is temporarily unavailable</Message> </Error> </DepositAccount>

    Error object can be present inside below objects (one or more) DepositAccount or/and <InvestmentAccount></InvestmentAccount> or <LoanAccount></LoanAccount> or <LocAccount></LocAccount>

    Any thoughts or comments on approach?

  4. Nat Sakimura reporter
    { 
    "DepositAccount": { 
    "AccountId": "1", 
    "Error": { 
    "Code": "700", 
    "Message": "Account information is temporarily unavailable" 
    } 
    } 
    }
    

    Edmund is going to investigate if it can be expressed in Swagger.

  5. Sascha Preibisch

    I would like us not to use "Error" in this context. It assumes that something went wrong which is not the case. I would rather like to introduce an "AccountStatus" key that indicates potential issues. By default it would be empty (or not included if it has no value). Something like this:

    Everything is ok: Empty AccountStatus: { "DepositAccount": { "AccountId": "1", "AccountStatus": {} } }

    Account is temporarily not available: AccountStatus has a value: { "DepositAccount": { "AccountId": "1", "AccountStatus": { "Code": "001", "Message": "Account information is temporarily unavailable" } } }

    As for "error codes" we may be able to maintain a list of "Code" values of all issues that come to our mind.

  6. Anoop Saxena

    So far when getting account details summary only two errors comes to mind

    700 Account information is temporarily unavailable 701 Account not found

  7. Log in to comment