search

paritytech / substrate-api-sidecar

REST service that makes it easy to interact with blockchain nodes built using Substrate's FRAME framework.
https://paritytech.github.io/substrate-api-sidecar/dist/
GNU General Public License v3.0
245 stars 151 forks source link

Use `pending_rewards` for claimed info in related endpoints #1452

Open Imod7 opened 3 months ago

Imod7 commented 3 months ago

Description Track this issue https://github.com/paritytech/polkadot-sdk/issues/4313 to see when pending_rewards are in production so it can be used for the claimed information in the related endpoints (staking-info, staking-payouts).

More info

Related to https://github.com/paritytech/substrate-api-sidecar/pull/1445

IkerAlus commented 3 months ago

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.

Imod7 commented 3 months ago

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.

IkerAlus commented 3 months ago

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 https://github.com/paritytech/substrate-api-sidecar/pull/1445