feat: query latest block info #31
Conversation
db/bbolt.go
Outdated
| return types.ErrBlockNotFound | ||
| } | ||
|
|
||
| // Iterate backwards to find the earliest consecutive block |
There was a problem hiding this comment.
this is good enough for now. a few possible improvements:
- record the earliest consecutive block in the DB. so this becomes O(1)
- use the exponential strategy to search backwards so it will be
O(logN)- since we only insert consecutively, there won't be a case where we skipped blocks in between
I think 1 is better because if we choose 2, every time people visit the site, we will do the same calculation again. btw can you create a follow-up task in Linear? it will be a good ramp-up task for new team members
There was a problem hiding this comment.
got it, yes i think 1 make sense (similar to what we have for latest consecutively finalized block)
however this is just a rough and ready code which may be superseded if we refactor to psql. as discussed offline, let's wait for @SebastianElvis to confirm before making this change
There was a problem hiding this comment.
Imo option 1 makes more sense as well, and this algorithm and corresponding interfaces will apply even if we switch to psql later on. Wdyt?
Btw, have we made any decision on embedded DB vs psql? I remember the conclusion was to follow embedded DB for now
There was a problem hiding this comment.
yes we discussed in TG to use embedded DB. but for production deployment, we use docker containers anyway so it's better to do external DB
but we will support both embedded psql and external psql db mode
There was a problem hiding this comment.
okay, so we can leave this one for now since it will be updated by the psql refactor
db/bbolt_test.go
Outdated
| first := &types.Block{ | ||
| BlockHeight: 1, | ||
| BlockHash: "0x123", | ||
| BlockTimestamp: 1000, | ||
| } | ||
| third := &types.Block{ | ||
| BlockHeight: 3, | ||
| BlockHash: "0x456", | ||
| BlockTimestamp: 1050, | ||
| } |
There was a problem hiding this comment.
per my comment above, there won't be a case that we have block 1, 3 but not 2
please correct me if my memory is incorrect
There was a problem hiding this comment.
got it, i'll update the logic to simply fetch the earliest block in the db.
|
thanks @SebastianElvis - i added one more commit to address @bap2pecs comment above on consecutive quorum. feel free to take a quick look! otherwise we can merge the two stacked prs |
Summary
This stacked PR (following #30) adds a new HTTP api route to return the latest block info, including:
to be displayed by the finality explorer
Test plan