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

GraphQL query for a specific block (within transition frontier) #7404

Closed
bkase opened this issue Jan 9, 2021 · 8 comments
Closed

GraphQL query for a specific block (within transition frontier) #7404

bkase opened this issue Jan 9, 2021 · 8 comments

Comments

@bkase
Copy link
Member

bkase commented Jan 9, 2021

We currently have a bestChain query that returns blocks on the best chain within the transition frontier but we don’t have a way to query for individual blocks via hash or height from this interface.

This is very very simple to add from an implementation perspective and is useful.

@bkase bkase added the easy label Jan 9, 2021
@bkase bkase added this to Discuss in MainNet Jan 9, 2021
@bkase
Copy link
Member Author

bkase commented Jan 9, 2021

implementation cost is 5min + overhead of landing a PR

Near zero risk of introducing any regressions

@crackerli
Copy link

Please don't forget to add the following input:
before: (block number)
after: (block number)
relatedTo: (publicKey)
first: first n elements
last: last n elements

and following output
pageInfo {
firstCursor
hasNextPage,
hasPreviousPage,
lastCursor
}

totalCount

these fields would help front-end work easily.

@bkase
Copy link
Member Author

bkase commented Jan 12, 2021

@crackerli this endpoint is always limited to returning a list of at most size 290 (pending small changes to consensus constants). As such I think the paging system isn’t necessary. Before/after doesn’t add anything on top of height.

relatedTo, first n, last n in bestChain. Should be easy enough to add though

@crackerli
Copy link

@crackerli this endpoint is always limited to returning a list of at most size 290 (pending small changes to consensus constants). As such I think the paging system isn’t necessary. Before/after doesn’t add anything on top of height.

relatedTo, first n, last n in bestChain. Should be easy enough to add though

So, if the user has 291 transactions, he may can not see the earliest transaction?

@garethtdavies
Copy link
Contributor

So, if the user has 291 transactions, he may can not see the earliest transaction?

@crackerli it's 290 blocks. If the user's transactions happened outside of those 290 blocks you would have to get from somewhere else e.g. archive node.

@crackerli
Copy link

So, if the user has 291 transactions, he may can not see the earliest transaction?

@crackerli it's 290 blocks. If the user's transactions happened outside of those 290 blocks you would have to get from somewhere else e.g. archive node.

Thank you much, I understood

@aneesharaines aneesharaines added this to Backlog in Product Prioritization Redux via automation Jan 15, 2021
@aneesharaines aneesharaines moved this from Discuss to To do in MainNet Jan 19, 2021
@psteckler psteckler self-assigned this Jan 20, 2021
@psteckler psteckler moved this from To do to Done in MainNet Jan 22, 2021
@robinbb
Copy link
Collaborator

robinbb commented Oct 12, 2022

@psteckler I perceive that this issue should be closed. Is that right?

@psteckler
Copy link
Member

Yes, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

6 participants