Skip to content

Conversation

@lok52
Copy link
Contributor

@lok52 lok52 commented Apr 11, 2021

Closes #538

indexed: true,
name: 'messageId',
type: 'bytes32'
},
Copy link
Member

Choose a reason for hiding this comment

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

Why did you modify this ABI?
It is a legacy ABI from the older version of AMB, where events had different signatures:

  • UserRequestForSignature(bytes) instead of UserRequestForSignature(bytes32,bytes)
  • UserRequestForAffirmation(bytes) instead of UserRequestForAffirmation(bytes32,bytes)

Since these signatures are already present in history of the production bridge, we should account for both types of events.


async function getPastEvents(contract, options) {
if (MONITOR_CACHE_EVENTS !== 'true') {
return commonGetPastEvents(contract, options)
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to use getPastEventsWithAPIFallback here?

url.searchParams.append('toBlock', options.toBlock || 'latest')
url.searchParams.append('topic0', web3.eth.abi.encodeEventSignature(abi))

const logs = await fetch(url).then(res => res.json())
Copy link
Member

Choose a reason for hiding this comment

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

From the Etherscan API docs: For performance & security considerations, only the first 1000 results are return. So please narrow down the filter parameters.
Seems that we need to request events in batches by using some sort of pagination logic.

@akolotov
Copy link
Collaborator

@LyzeOfKiel @k1rill-fedoseev what do you think if the graph on BSC is used instead of Etherscan API?

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