Repository navigation
[Feature] Declarative Calls Feedback #5445
Description
Description
I spent some time trying to add declarative calls (#5264) to messari's compound v3 subgraph as it uses a lot of eth_calls. I wasn't able to fully test any of this yet due to this blocker (#5444), however I had some feedback or requests for use cases that showed up when I was working to cut over the subgraph to use declarative calls.
- Using an
eth_callas input for anothereth_call, here is a real example:
const utilization = cometContract.getUtilization();
const borrowRate = cometContract.getBorrowRate(utilization).toBigDecimal();
const supplyRate = cometContract.getSupplyRate(utilization).toBigDecimal();- Multiple calls on one handler for the same function call with different input:
calls:
Comet.totalsBasic: Comet[event.address].totalsBasic(event.params.liquidator)
Come.totalsBasic: Comet[event.address].totalsBasic(event.params.borrower)Note: This may be possible to do already, but I am not sure
Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
Some information to help us out
- Tick this box if you plan on implementing this feature yourself.
- I have searched the issue tracker to make sure this issue is not a duplicate.
Activity
juanmardefago commentedon May 30, 2024
I've been playing a bit with declarative eth_calls too, and while doing so I also got into a similar situation, not entirely the same, but close.
Due to the limitations on what you can declare (only event.address or event.params.), I couldn't get my refactor to work, since the value I want to use for the contract address part isn't in the event.address or the params, but rather as either a field in a particular entity at that moment in time, or (by doing some workarounds) as a hardcoded value).
I'm thinking it's virtually the same issue described here in the first bullet point, even if the value to be used isn't really a response from a previous contract, but rather a hardcoded value/value from an already existing entity.
azf20 commentedon May 30, 2024
Thanks both this is great feedback.
@lutter what do you think on the "dependent calls" case?
@juanmardefago can you share a link to the existing handler so we can take a look at the "entity field input" example?
lutter commentedon Jun 3, 2024
It's already possible to have multiple calls on the same event handler. Just give it different labels, and that works; something like
The things that are not supported yet are:
Contract['0xdeadbeef'].function())juanmardefago commentedon Jun 3, 2024
An example of why we would want to have either hardcoded values or dynamic values would be this one
In this case, we take the value from an internal constant (so it could be hardcoded) but it could also be taken from the entity itself, so there might be some potential use cases where the value isn't always potentially hardcoded, as it might change over time, but it's not part of the event, but rather stored in an entity, and by the time the call needs to be done, the address to be used in the call needs to be retrieved from that entity.
Currently, you can't do declarative calls if it happens to have any of those two cases unfortunately (the core network subgraph's most used eth_call is the first example
github-actions commentedon Dec 9, 2024
Looks like this issue has been open for 6 months with no activity. Is it still relevant? If not, please remember to close it.
dimitrovmaksim commentedon Oct 21, 2026
Hi!
We're refreshing the graph-node issue backlog to help focus on current priorities and make it easier to track and address relevant issues. As part of this cleanup, we're closing issues created in 2025 or earlier.
If this issue is still relevant, please open a new issue (linking back to this one) or leave a comment here with any updated context and tag @dimitrovmaksim, so we can reassess and prioritize it.
Thank you for your contributions to graph-node! 🙏