Update sushiswap-subgraph stack to point to filecoin endpoint #509
No reviewers
Labels
No Label
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
in progress
invalid
question
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/stack-orchestrator#509
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "pm-sushigraph-filecoin"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of https://github.com/cerc-io/stack-orchestrator/issues/495
After following log appears in the
graph-node
container, block entities created by theblocks
subgraph can be checked using a GQL request to the subgraph endpoint:Find out the mapped host port for the subgraph endpoint:
Make following GQL request at the endpoint
http://127.0.0.1:<HOST_PORT>/subgraphs/name/sushiswap/blocks/graphql
:On running the
v3
subgraph withstartBlock
set to3143725
(skipping blocks to get to the firstPoolCreated
event at3143728
), getting the following error ingraph-node
:The
blocks
subgraph seems to be running fine for historic blocks (ran for>5000
blocks afterstartBlock
):On trying to run it near head by redeploying with
startBlock
set to3145500
(head at3146000
), getting a recurring "non-fatal error" after some time with slowed down processing of blocks ingraph-node
:On running the
v3
subgraph withstartBlock
set to3143725
(skipping blocks to get to the firstPoolCreated
event at3143728
), getting the following error ingraph-node
when it tries to process theTransfer
andIncreaseLiquidity
events from theNonfungiblePositionManager
contract:The above error from
NonfungiblePositionManager
contract seems to be occurring from thepositions
method:https://github.com/sushiswap/v3-periphery/blob/master/contracts/NonfungiblePositionManager.sol#L100
In the
v3
subgraph'sTransfer
event handler, apositions
eth_call is made to the NFPM contract:https://github.com/sushiswap/subgraphs/blob/master/subgraphs/v3/src/mappings/position-manager.ts#L205
https://github.com/sushiswap/subgraphs/blob/master/subgraphs/v3/src/mappings/position-manager.ts#L18
We get the same error on making the eth_call maually (using
ethers
) at the transaction height:However, if we make the call at next block (
3143729
) or without a block tag (latest
), the expected result is returned.After increasing the number of miners to 3 in the Lotus fixturenet, we see multiple blocks being included at some tipset heights (checked using
Filecoin.ChainGetTipSetByHeight
RPC call).On doing transactions with a dummy ERC20 contract (transfers), the state change (balance) is reflected at height at which the transaction happened.
Same behaviour is seen regardless of whether or not there are multiple blocks at tipset height with the transaction.
While running the subgraph against Lotus fixturenet, we get the following error in
graph-node
when it tries to process thePoolCreated
event:The error occurs because of
nativePricePool
being not set in the config used for subgraph deployment.On an earlier run with the fixturenet (without the
graph-node
fix), it was running into thenull
block error even before reaching this point.For Filecoin mainnet, the config had been updated with the required properties:
https://github.com/sushiswap/subgraphs/blob/master/config/filecoin.js
This works against the latest tipset on the Glif API endpoint:
I suspect the issue is related to the way that Lotus applies tipset messages when performing the call on a specific height. In this particular case, it seems like the client is asking for height 3143728, which is where the first pool was created: https://filfox.info/en/address/f410f6tltgjwbhjh4l7l2azbbpyjhqdu32ywd2axlm6y.
I'd imagine that before that transaction, this assertion would've failed. After that transaction, the assertion likely passes.
So my theory is that
eth_call
is not applying the transaction before executing the call.I was able to reproduce and confirm my hypothesis against the Vulcanize endpoint.
This observation implies that the deferred execution model is not being correctly reconciled for
eth_call
when requesting a concrete epoch number. You ask to perform a call on top of epoch 3143728. In Eth semantics, this means "apply this message on the output state after 3143728, which happens to be the state root specified in the block header". In Filecoin, this should translate to: "apply this message on the parent state root of the next epoch". In the Eth API, we ensure that what (Eth-assuming) clients see matches the expectations Ethereum's immediate execution model, but I suspect that's not being done correctly here.Could you please check what the value of this env variable is in the Lotus nodes backing your endpoint?
LOTUS_SKIP_APPLY_TS_MESSAGE_CALL_WITH_GAS
. There is a rather nasty and bespoke optimization that might be interferring here.Subgraphs seem to be working now against the vulcanize endpoint
No errors are seen in graph-node container logs
Blocks subgraph seems to be processing blocks slower than v3 subgraph
v3 subgraph processed till
3,154,721
(head was at3,154,983
;~250
blocks behind)Also, subgraphs take some time to start processing after deployment:
~11 mins
Blocks subgraph:
v3 subgraph: