Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pool Delegators History endpoint returns incorrect active epoch nr #79

Closed
1 of 4 tasks
t0m3kf opened this issue Oct 4, 2022 · 7 comments
Closed
1 of 4 tasks

Comments

@t0m3kf
Copy link

t0m3kf commented Oct 4, 2022

What operating system are you using, and which version?

  • Linux / Ubuntu
  • Linux / Other
  • OSX
  • Windows

Steps to Reproduce

curl -X GET "https://api.koios.rest/api/v0/pool_delegators_history?_pool_bech32=pool19xyfanyp28j6j07dxgwdjp0wur6seqmyyu64qgzstzl7s47pvpj" -H "Accept: application/json"

Expected Behavior

Should return list of delegators and active epoch numer for every delegator

Actual Behavior

Returns the same epoch number for every delegator

@rdlrt
Copy link

rdlrt commented Oct 4, 2022

Not sure if this is the right repo, you might want to raise in koios-artifacts instead

The expected behaviour mentioned in specs is absence of an epoch_no will give you current epoch. You need to pass it epoch_no you want to query for, as bringing forever all history by default is not really a sustainable way to work (even if feature request was raised and consensus was to change the query to show all history for short term), especially when doing join across tables (guildnet for instance is over 7000 epochs long, even pagination doesnt make sense for such queries in that case, when consisting information across different tables).

PS: If there is a strong case otherwise (for instance considering account history where you can supply bulk requests of accounts already), raise a feature request and we can surely work that out for short to mid term

@t0m3kf
Copy link
Author

t0m3kf commented Oct 4, 2022

It's the same behaviour even when the epoch_no is specified in request

curl -X GET "https://api.koios.rest/api/v0/pool_delegators_history?_pool_bech32=pool19xyfanyp28j6j07dxgwdjp0wur6seqmyyu64qgzstzl7s47pvpj&_epoch_no=365" -H "Accept: application/j
son"

Then it returns all the delegators for a given epoch but active epoch equals _ecpoh_no specified in the request...

@rdlrt
Copy link

rdlrt commented Oct 4, 2022

Then it returns all the delegators for a given epoch but active epoch equals _ecpoh_no specified in the request

That is the description of the endpoint 🙂

@t0m3kf
Copy link
Author

t0m3kf commented Oct 4, 2022

What's the benefit of returning epoch number that I specify in the request? I though the point of this endpoint is to get historical data for past epochs just like in Pool Delegators List endpoint (https://api.koios.rest/api/v0/pool_delegators) and to find out when a given stake address (delegator) become active in the pool

@rdlrt
Copy link

rdlrt commented Oct 4, 2022

the benefit of returning epoch number that I specify in the request

fair point, I agree it may not make sense to return it again, believe it might've been artifact from before (as history was created using delegators as baseline)

data for past epochs

As mentioned in first reply, it's not gonna be sustainable in long future, but if you rely heavily on returning all delegators for all epochs, happy to get that back until this becomes an issue. Can I request you though to raise change request on koios-artifacts repo?

@t0m3kf
Copy link
Author

t0m3kf commented Oct 4, 2022

Thanks for explanation. It makes more sense now

I've adopted my scripts/workflow to use Pool Delegator List instead of history anyway so there's no really need for this feature for me but was just confused when I tried to use it.

@t0m3kf t0m3kf closed this as completed Oct 4, 2022
@rdlrt
Copy link

rdlrt commented Oct 5, 2022

@t0m3kf - this request will be (atleast until manageable) included in koios-1.0.8 , you can check out https://guild.koios.rest - which has already been upgraded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants