Fix getLog
API to use log_cids
table
#92
No reviewers
Labels
No Label
bug
critical
documentation
duplicate
enhancement
Epic
good first issue
help wanted
Integration tests
invalid
question
v5
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/ipld-eth-server#92
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "fix-get-logs"
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?
ipld-eth-indexer
use statediff geth instead.Fixes: #87 and https://github.com/vulcanize/ipld-eth-indexer/issues/84
@ashwinphatak Can you specify the CLI flags we use to run to the server? Wanted to cross-check if the CLI is not broken by my changes.
I'm using:
ipldBlock
should be the log, not the receipt.@ -69,3 +69,3 @@
# CID for the Receipt IPLD block this Log exists in.
# CID for the leaf node IPLD block of the log.
cid: String!
Nit: Indentation is different from above.
LGTM, added some minor comments.
@ -0,0 +4,4 @@
leaf_cid TEXT NOT NULL,
leaf_mh_key TEXT NOT NULL REFERENCES public.blocks (key) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
receipt_id INTEGER NOT NULL REFERENCES eth.receipt_cids (id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
address VARCHAR(66) NOT NULL,
Just a heads up, this is not
NOT NULL
in the migration that is in go-ethereum@ -107,3 +109,4 @@
if pea.ethClient != nil {
if header, err := pea.ethClient.HeaderByHash(ctx, hash); header != nil && err == nil {
go pea.writeStateDiffFor(hash)
We can just pass
RPCMarshalHeader(header, pea.B.Config.ChainConfig.Clique != nil)
instead of allocating this bool (here and on line 1092 and 1113), super insignificant optimization but I actually think it makes the code cleaner/less cluttered. Up to you.@ -168,7 +166,7 @@ func (f *IPLDFetcher) FetchRcts(tx *sqlx.Tx, cids []eth.ReceiptModel) ([]ipfs.Bl
}
This isn't fetching anything, it's decomposing the already fetched logResults.
Same here, not actually fetching IPLDs
@ -0,0 +4,4 @@
leaf_cid TEXT NOT NULL,
leaf_mh_key TEXT NOT NULL REFERENCES public.blocks (key) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
receipt_id INTEGER NOT NULL REFERENCES eth.receipt_cids (id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
address VARCHAR(66) NOT NULL,
I have added a note in this task https://github.com/vulcanize/go-ethereum/issues/73
I will update the schema once we have a single repo for the DB schema.
Done
@ -69,3 +69,3 @@
# CID for the Receipt IPLD block this Log exists in.
# CID for the leaf node IPLD block of the log.
cid: String!
Done
@ -107,3 +109,4 @@
if pea.ethClient != nil {
if header, err := pea.ethClient.HeaderByHash(ctx, hash); header != nil && err == nil {
go pea.writeStateDiffFor(hash)
Done
@ -168,7 +166,7 @@ func (f *IPLDFetcher) FetchRcts(tx *sqlx.Tx, cids []eth.ReceiptModel) ([]ipfs.Bl
}
Updated the function name.
@ -168,7 +166,7 @@ func (f *IPLDFetcher) FetchRcts(tx *sqlx.Tx, cids []eth.ReceiptModel) ([]ipfs.Bl
}
Updated the function name.
Receipt => Log in the comment?
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
What will this return for pre-byzantium fork records?
https://ethereum.stackexchange.com/questions/28889/what-is-the-exact-meaning-of-a-transactions-new-receipt-status-field
@ -70,3 +70,3 @@
# CID for the Receipt IPLD block this Log exists in.
# CID for the leaf node IPLD block of the log.
cid: String!
This is always returning an empty string.
@ -70,3 +70,3 @@
# CID for the Receipt IPLD block this Log exists in.
# CID for the leaf node IPLD block of the log.
cid: String!
Done
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
@ashwinphatak
As per my understanding pre-byzantium fork, we used to return
PostState
which is the root and if it is not present then we return thestatus
.For GQL we need to change the type of status to
Bytes!
so it can accommodate both. Or should I add two separate fieldsroot
andstatus
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
Root of what? Is there some notion of success/failure by inspecting the
PostState
?@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
Intermediate state root when the transaction is being applied if the transaction fails
Source: https://github.com/ethereum/EIPs/issues/98#issue-151094725
But then they removed the
root
field and addstatus
in EIP-658 this field was replaced bystatus
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
As per https://eips.ethereum.org/EIPS/eip-658, "With the introduction of the REVERT opcode in EIP140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas".
So, we may be able to return 1 or 0 based on whether the tx consumed all gas for pre-byzantium blocks?
@i-norden what do you think?
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
I don't think we can assume whether or not a tx failed based on how much of the gas limit was used.
If a tx is reverted early on in its execution, due to some programmatic failure of an OPCODE execution, then it can be reverted early on and the amount of gas used can be much lower than the limit allocated. But, if a tx reverts because there is not enough gas allocated, then it will only revert after the miner has executed all of the OPCODEs it can afford to before bumping up against the limit and realizing there is not enough left to finish execution. In this case the reverted tx may use all or most of the gas limit.
Another edge cases that make this approach infeasible is, for example, if someone vastly overestimated the gas limit needed for a tx. The tx is properly executed but done so far below the allocated limit, so using this heuristic the tx would look like it failed when it didn't.
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
Oh I misread, you meant for pre-byzantium blocks. So I just stated the obvious.
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
Theoretically it is possible that a tx uses up the entire gas limit during normal, successful execution- no? But the statement in that EIP makes it sound like it is a safe assumption.
@ -75,2 +79,4 @@
# Status of the Receipt IPLD block this Log exists in.
status: Int!
}
Done
Done
Left some comments, I need some clarification on some things and some changes need to be done. Also, my main hangup is that we are breaking compatibility with the regular eth json rpc endpoint with these changes, so I think that requires some further discussion.
@ -9,6 +9,7 @@ CREATE TABLE eth.transaction_cids (
dst VARCHAR(66) NOT NULL,
Let's call this gas_limit, it's more accurate to how things are defined in EIPs/specs and more explicit about what it is/how it is used.
A problem with this is that this deviates from the normal, expected behavior of this eth json-rpc endpoint. The regular endpoint only fills in the status if it is explicitly known: https://github.com/ethereum/go-ethereum/blob/master/internal/ethapi/api.go#L1650. So this breaks compatibility with the regular endpoint.
We still want to fill in the
fields["root"]
if receipt.PostState is present, whether or not we can also assume the status above.I'm missing something. When will receipt.GasUsed ever be more than tx.Gas()? When a tx fails for whatever reason is it's receipt.GasUsed simply set to something above the tx.Gas() to indicate it failed? Seems odd but I'm not super familiar with this pre-byzantium behavior- wouldn't it need to track/report how much gas was actually used during the failed execution/reversion (because the tx sender still has to pay for whatever execution was performed prior to it reverting/failing)?
Added an issue to track this https://github.com/vulcanize/ipld-eth-server/issues/102
Ran watcher-ts smoke tests against this, tests passed.
LGTM. We might want to go ahead and update the schema.sql, or not since we want to move to using ipld-eth-db for migrations/schema. Depends how soon you think we will remove the migrations/schema from here and rely on ipld-eth-dn. If soon then don't worry about it, if it will be some time (weeks) then go ahead and update the schema file here.
I am picking up the task for moving the schema to
ipld-eth-db
next. Should be done by next week.