Add GET redelegation endpoint and querier

[fedekunze]

#2139 is missing redelegation querier and redelegation endpoint that needs to be implemented for #2113:
GET /stake/delegators/{delegatorAddr}/redelegations/validator_from/{validatorSrcAddr}/validator_to/{validatorDstAddr}.

Please note that the GetRedelegation keeper is already done

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ValarDragon]

Seeing as the tag here was changed from if-have-time-prelaunch to prelaunch, I'm presuming its needed / blocking something for voyager?

[fedekunze]

Not really for Voyager, but mostly because of the LCD spec (#2113), which is labeled prelaunch

[fedekunze]

@faboweb @jackzampolin @cwgoes @HaoyangLiu do you think we require to have this functionality of querying a single redelegation ? According to Fabo it might not be required since clients will most of the time do query all of them at once. Thoughts ?

[jackzampolin]

I think we need this functionality for individual delegation viewing screens. Also does the group of delegations endpoint allow for filtering by user? I have a feeling theres a lot of UI that would require the ability to show all the delegations by an individual user.

[sunnya97]

/stake/delegators/{delegatorAddr}/redelegations/validator_from/{validatorSrcAddr}/validator_to/{validatorDstAddr} seems like bad REST-ful API 😞

Can't we use the GET data field instead of URL params?

[alexanderbez]

Seems like /stake/delegators/{delegatorAddr}/redelegations should be the resource GET endpoint with query params.

[jackzampolin]

Agree with @alexanderbez and @sunnya97 here. We should push this into query params.

[fedekunze]

actually shouldn't /stake/delegators/{delegatorAddr}/redelegations/validator_from/{validatorSrcAddr}/validator_to/{validatorDstAddr} return an array of redelegations instead of a single one ? what if the user redelegates first only a partial amount of atoms and then the rest ? will be there a conflict with the key ? cc: @alexanderbez @cwgoes @jackzampolin @sunnya97 ?

[alexanderbez]

Huh? What wrong with /stake/delegators/{delegatorAddr}/redelegations?validator_from={validatorSrcAddr}&validator_to={validatorDstAddr}?

Obviously we'd perform sanity/validation checks.

[fedekunze]

Huh? What wrong with /stake/delegators/{delegatorAddr}/redelegations?validator_from={validatorSrcAddr}&validator_to={validatorDstAddr}?

I'm not opposed to use query parameters

[alexanderbez]

Great! And /stake/delegators/{delegatorAddr}/redelegations would get you all the redelegations I presume.

[sunnya97]

It should be /stake/delegators/{delegatorAddr}/redelegation?validator_from={validatorSrcAddr}&validator_to={validatorDstAddr} right? Singular redelegation, not plural.

Alternatively, I can do create the endpoint:
/stake/redelegations?delegator={delegatorAddr}&validator_from={validatorSrcAddr}&validator_to={validatorDstAddr}
and use that for all redelegations queries, including all those from a specific validator (for example, even replacing the /stake/validators/{validatorAddr}/redelegations). I actually prefer this model.

[alexanderbez]

Ahhh yes there can only be a single redelegation, so yes singular. I like the later model you mentioned as well.

[fedekunze]

I'd go with the first one with queries bc /stake/redelegations (without any query) doesn't make sense (why would you want to return all redelegations from everyone). So I propose:

• /stake/delegators/{delegatorAddr}/redelegation?validator_from={validatorSrcAddr}&validator_to={validatorDstAddr}: return all reds from a delegator (+ query)
• /stake/validators/{validatorAddr}/redelegation?delegator={delegatorAddr}&validator={validatorAddr}: return all reds from a validator (from or to + query)

[sunnya97]

why would you want to return all redelegations from everyone

I can see a block explorer or some cool delegation visualizer wanting to do that

/stake/validators/{validatorAddr}/redelegation?delegator={delegatorAddr}&validator={validatorAddr}: return all reds from a validator (from or to + query)

In this one, is this redelegations to or from a specific validator?

If you really wanted to do this, this should be split into two endpoints:

• /stake/validators/{validatorAddr}/outgoing_redelegations?validator_to={dstValidatorAddr}&delegator={delegatorAddr}
• /stake/validators/{validatorAddr}/incoming_redelegations?validator_from={srcValidatorAddr}&delegator={delegatorAddr}

But I don't see why/how is this cleaner than having a single endpoint?

[faboweb]

I can see a block explorer or some cool delegation visualizer wanting to do that

you can still query all transactions of a certain type by using /txs, why misuse this endpoint for that purpose?

Ahhh yes there can only be a single redelegation, so yes singular.

no, resources are always in plural. for one delegator/validator there can be multiple redelegations that are filtered by the query parameters

Delegator redelegations endpoint I could go with:

/stake/delegators/{delegatorAddr}/redelegations?validator_from={validatorSrcAddr}&validator_to={validatorDstAddr}

For the validator redelegations I think the endpoint is already pretty solid:

/stake/validators/{validatorAddr}/redelegations?delegator={delegatorAddr}&validator={validatorAddr}: return all reds from a validator (from or to + query)

Clients can filter on incoming and outgoing redelegations based on the tx. Plus they only need to do one request instead of two.

Did any consumer of the API complain about its current form?

[sunnya97]

Having to use txs to query all redelegations or to filter between incoming vs outgoing redelegations seems suboptimal. Using tx tags is good for listening for events, but if a query can be done using state, that should be preferred.

[alexanderbez]

The same could be said for governance votes and deposits. Where do we draw the line?

[jackzampolin]

@alexanderbez This is a REALLY good question and I think that performance and feedback from clients should really drive this.