Use `pending_rewards` for claimed info in related endpoints about substrate-api-sidecar HOT 3 OPEN

Will this "simply" add a new field pending to the endpoint response? If that is the case, is this pending rewards information not available (doing a bit of local computation) in current and previous versions of the staking pallet? This way we would have a stable output format.

No, my intention was not to modify the endpoints' responses as soon as pending_rewards goes live, only to check if it can be used to simplify the internal calculations in our endpoints. The reason I added this issue was more of a tracker issue to re iterate through the logic as soon as it is available. It could potentially make the code simpler and more efficient.

Based on this comment for example, the response under claimed will now be something like this:

"claimedRewards": [
      {
        "era": "1322",
        "status": "claimed"
      },
      {
        "era": "1323",
        "status": "unclaimed"
      },
      {
        "era": "1324",
        "status": "partially claimed"
      },

which is calculated by currently comparing the results from 3 calls and quite a few if else statements. So if pending_rewards can be used to reduce this, maybe it is worth re iterating. Wdyt?

Note: I updated the More Info section in the Description to give some more context.

from substrate-api-sidecar.

So if pending_rewards can be used to reduce this, maybe it is worth re iterating. Wdyt?

Yes, that total makes sense. Bear in mind that this will simplify the logic from the relevant spec version onwards, but for previous ones, we will still need to maintain the more complex logic as introduced by #1445

from substrate-api-sidecar.

Will this "simply" add a new field pending to the endpoint response? If that is the case, is this pending rewards information not available (doing a bit of local computation) in current and previous versions of the staking pallet? This way we would have a stable output format.

from substrate-api-sidecar.