-
Notifications
You must be signed in to change notification settings - Fork 75
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
feat: add manual ci for querying grant role events #336
Conversation
viraj124
commented
Oct 15, 2024
•
edited
Loading
edited
- closes (feat): add manual ci for querying grant role events #337
This PR is published in NPM with version 1.1.0-pr-336-58 |
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 'd say that instead of just logging the events, we pick every address that was ever granted a role, and then query hasRole, and filter those that currently have a role assigned. That way we build a summary of currently active roles in the contract (and who holds them)
Ideally we also can match the role IDs against well known roles that we have, like DEFAULT_ADMIN, PAUSER, COMMITTER... and log those role IDs that we do not recognise.
|
||
try { | ||
const events = await contract.queryFilter( | ||
contract.filters.RoleGranted() |
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.
What happens when you query too many blocks?
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.
currently tested with a public rpc, triggering the ci frequently might result in rate limit issues, as currently we query all blocks.
With a private rpc we should be good, but I was also thinking if we can specify a block range too but for now decided to keep the number of inputs minimal, so didn't add that
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.
imo, hardhat tasks are not the ideal way to do this. Also why do we need this to be in the ci?
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 need to be able to manually trigger it by specifying contract address and rpc from the ci and there is no tool with a ui live currently that we can use for filtering events, there is a rate limit error risk with this approach but using a pvt rpc reduces that risk to a great extent
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.
imo, hardhat tasks are not the ideal way to do this. Also why do we need this to be in the ci?
Please propose alternatives. I am tempted to use external infra for this task, like envio.
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 guess we can use the graph protocol or quickly spin up our own indexer using ponder.sh
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.
The types are a bit all over the place, opened this in my IDE and saw a lot of red