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

improve(indexer): add block timestamp to depositevent data #129

Merged
merged 3 commits into from
Dec 16, 2024

Conversation

daywiss
Copy link
Contributor

@daywiss daywiss commented Dec 5, 2024

motivation

We want to store block timestamps with deposit data in order to calculate some metrics

changes

This adds a column "blockTimestamp" to v3FundsDeposited, and queries per block range all the block timestamps and adds it to the data when storing in database

profiling

We will use this new value and the existing "createdAt" value, which is our insertion time, for instance:
const depositWriteTime = toSeconds(deposit.createdAt) - deposit.blockTimestamp

Copy link

linear bot commented Dec 5, 2024

@@ -89,4 +89,7 @@ export class V3FundsDeposited {

@CreateDateColumn()
createdAt: Date;

@Column({ nullable: true })
blockTimestamp?: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something we will eventually backfill? Could be a good candidate to make required with the prod backfilling

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im not totally sure how this works by making it required, i wanted to avoid having to rerun indexing to get this data, and allow it optionally going forward

@@ -46,6 +47,7 @@ export class SpokePoolRepository extends dbUtils.BlockchainEventRepository {
...this.formatRelayData(event),
quoteTimestamp: new Date(event.quoteTimestamp * 1000),
finalised: event.blockNumber <= lastFinalisedBlock,
blockTimestamp: blockTimes[event.blockNumber],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about considering quoteTimestamp as deposit date? I know there might be a tiny difference with the actual block number though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the most accurate will be to track the time when the user's tx got mined

Comment on lines 126 to 128
private async getBlockTimesByRange(
blockRange: BlockRange,
): Promise<Record<number, number>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's room for optimisation here. Instead of passing the whole block range, we can pass here a list with only the blocks we got deposit events for.
This will avoid fetching thousands of blocks with no events during backfilling

@@ -46,6 +47,7 @@ export class SpokePoolRepository extends dbUtils.BlockchainEventRepository {
...this.formatRelayData(event),
quoteTimestamp: new Date(event.quoteTimestamp * 1000),
finalised: event.blockNumber <= lastFinalisedBlock,
blockTimestamp: blockTimes[event.blockNumber],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the most accurate will be to track the time when the user's tx got mined

@daywiss daywiss requested a review from amateima December 6, 2024 15:59
@daywiss
Copy link
Contributor Author

daywiss commented Dec 6, 2024

@amateima I made 2 changes:

  1. optimized the block timestamp query to only care about blocks where we have deposit events
  2. log out the time difference directly after saving, so we can use datadog immediately

@daywiss daywiss merged commit 9e39da3 into master Dec 16, 2024
3 checks passed
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

Successfully merging this pull request may close these issues.

4 participants