-
Notifications
You must be signed in to change notification settings - Fork 1
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
rev2 of fast-usdc indexing #50
Conversation
@@ -327,10 +327,38 @@ enum FastUsdcTransactionStatus { | |||
|
|||
type FastUsdcTransaction @entity { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FR1.4: MUST Enable search by transaction ID or addresses
I think the id
in this entity is the original EVM transaction ID right? That's what we want, so just making sure.
FR2.2: MUST Show all transaction timestamps:
- Source Chain Transaction Time
- LP Funds Disbursement
- CCTP Transaction Completion
- LP Settlement Time
Looks like sourceBlockTimestamp
covers "Source Chain Transaction Time". Do we need to add timestamps to all the other status changes, or are they inferable somehow already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also:
FR1.1: MUST Display paginated list of all Fast USDC transactions
It's reasonable to assume these have to be ordered in some way, like by sourceBlockTimestamp
. It would be helpful to see an example query in the PR description to verify that it is possible after this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the id in this entity is the original EVM transaction ID right? That's what we want, so just making sure.
Correct
Looks like sourceBlockTimestamp covers "Source Chain Transaction Time".
Agreed
Do we need to add timestamps to all the other status changes, or are they inferable somehow already?
Thanks, that's a big gap in the existing functionality. I had planned to get that from other chains. I'll see about adding it here.
@@ -6,6 +6,8 @@ | |||
"declaration": true, | |||
"importHelpers": true, | |||
"resolveJsonModule": true, | |||
"strict": true, | |||
"noImplicitAny": false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, is this because of a rough edge in @subql or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually Agoric deps. I've filed an issue,
3047531
to
6e38078
Compare
2c23e96
to
c6bbb85
Compare
c6bbb85
to
a4d4ca3
Compare
Replacing with a new repo: https://github.com/Agoric/opco-subql/ |
Fixes these fields
Adds these fields
And these height records:
Makes the indexer able to accomodate presence of OBSERVED records and backfill the missing data
A bunch of dep updates and patches to get things working right