-
Notifications
You must be signed in to change notification settings - Fork 104
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
accounts + native transfers #1210
base: v0.8
Are you sure you want to change the base?
Conversation
const blocks = Array.from( | ||
{ length: interval[1] - interval[0] + 1 }, | ||
(_, i) => interval[0] + i, | ||
); |
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 would feel a little better about this if we just used an array and a for loop
if (block.transactions.find((t) => t.hash === hash) === undefined) { | ||
throw new Error( | ||
`Detected inconsistent RPC responses. 'trace.blockHash' ${callTrace.blockHash} does not match 'block.hash' ${block.hash}`, | ||
`Detected inconsistent RPC responses. 'trace.transactionHash' ${hash} not found in 'block.transactions' ${block.hash}`, | ||
); | ||
} |
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.
nice
let traces = await _debug_traceBlockByNumber(args.requestQueue, { | ||
blockNumber: toHex(blockNumber), | ||
}); |
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.
When I was evaluating the debug rpc methods, I notice that traceBlockByHash
was often way faster than traceBlockByNumber
. It would require a different algorithm because block hash isn't immediately available, but something we should try before shipping
const syncTraces = await _debug_traceBlockByNumber(args.requestQueue, { | ||
blockNumber: toHex(blockNumber), | ||
}); |
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.
We should start to think about how we can avoid requesting the same block twice if there are multiple transfer and transaction filters
// }); | ||
|
||
// Remove traces that dont match transaction or transfer filter | ||
traces = traces.filter((trace) => { |
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 we need to do a depth first search over all the traces, either in this block or above where traces
is declared.
It performs three functions:
- processes child traces (each call can have several sub-calls)
- orders traces for
checkpoint.eventIndex
- determine failed traces
See sync-historical
ponder/packages/core/src/sync-historical/index.ts
Lines 324 to 368 in 2117cec
const dfs = ( | |
syncTrace: SyncTrace["result"][], | |
transactionHash: Hex, | |
parentTrace: SyncTrace["result"] | undefined, | |
) => { | |
for (const trace of syncTrace) { | |
if (filter.type === "transfer") { | |
if ( | |
isTransferFilterMatched({ | |
filter, | |
block: { number: toHex(blockNumber) }, | |
trace, | |
}) | |
) { | |
// TODO(kyle) handle factory | |
traces.push({ trace, transactionHash, position }); | |
} | |
} else { | |
if ( | |
isTransactionFilterMatched({ | |
filter, | |
block: { number: toHex(blockNumber) }, | |
trace, | |
}) | |
) { | |
// TODO(kyle) handle factory | |
traces.push({ trace, transactionHash, position }); | |
} | |
} | |
if (trace.error !== undefined) { | |
failedTraces.set(trace, trace.error); | |
} else if (parentTrace && failedTraces.has(parentTrace)) { | |
failedTraces.set(trace, failedTraces.get(parentTrace)!); | |
} | |
position++; | |
if (trace.calls) { | |
dfs(trace.calls, transactionHash, trace); | |
} | |
} | |
}; |
|
||
return { | ||
block, | ||
logs, | ||
factoryLogs, | ||
callTraces, | ||
traces, |
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.
Should this type be the same as ??
ponder/packages/core/src/sync-historical/index.ts
Lines 313 to 317 in 2117cec
const traces: { | |
trace: SyncTrace["result"]; | |
transactionHash: Hex; | |
position: number; | |
}[] = []; |
if (shouldRequestTraces) { | ||
const traces = await _trace_block(args.requestQueue, { | ||
traces = await _debug_traceBlockByNumber(args.requestQueue, { |
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.
Should use _debug_traceBlockByHash
. It's more robust when reorgs occur because it unambiguously refers to the exact block
} | ||
return isMatched; | ||
}); | ||
|
||
transactions = transactions.filter((t) => transactionHashes.has(t.hash)); | ||
transactionReceipts = transactionReceipts.filter((t) => |
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.
We should revisit this once we implement the includeTransactionReceipt
feature
if ( | ||
filter.includeReverted === false && | ||
(trace.revertReason !== undefined || trace.error !== undefined) | ||
) { | ||
return 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.
It's not super clear, this function returns true for the case "should this trace be saved in the database" and not "does this trace exactly match the filter such that it will cause an indexing function to run". The reason for the distinction is that we don't want the cache to be completely useless when the filter type slightly changes. For that reason this check should be removed.
In this example, if the user decides that they want to include reverted traces after they have already fully synced their app, every block will need to be resynced.
Maybe we could add some comments acknowledging the properties that are ignored.
Hello guys; I have a pressing timeline on getting something for native transfers and would like to explore using this here... Do you think it will be ready within next 1/2 weeks? Any timeline in mind? Thank you in advance. |
We're hoping to get a prerelease out in the next few days, but don't want to make any promises on when we will release v0.8. |
isTransactionFilterMatched({ | ||
filter: { | ||
...filter, | ||
fromAddress: fromAddress, | ||
toAddress: toAddress, | ||
}, | ||
block, | ||
transaction, | ||
}) |
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 like this, do you think we could get around overriding filter.fromAddress
by adding an optional parameter fromChildAddresses: Set<Address>
? Then we could reuse this in sync-realtime
as well
@@ -173,6 +208,36 @@ export const createRealtimeSync = ( | |||
} | |||
} | |||
|
|||
const isFactoryAddressMatched = ({ |
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.
Could get rid of this if we update is[type]FilterMatched
to handle factories
Closes #1157 #1198 #1205
Tasks
sync
TransactionFilter
typeTransferFilter
typeTraceFilter
type_debug_traceBlockByNumber
+_debug_traceBlockByHash
TransactionFilter
fragmentsTransferFilter
fragmentsTraceFilter
fragmentsisTransactionFilterMatched
isTransferFilterMatched
isTraceFilterMatched
traces
table, dropcallTraces
decodeEvents
buildEvents
getEvents
sync-historical
syncTrace
syncTransaction
checkpoint.eventIndex
traceCache
sync-realtime
fetchBlockEventData
handleBlock
API
AccountSource
ponder.config.ts
buildConfigAndIndexingFunctions