-
Notifications
You must be signed in to change notification settings - Fork 465
Decode log arguments in awaitTransactionSuccessAsync
#1995
Conversation
8b67e2d
to
23188d7
Compare
|
awaitTransactionSuccessAsync
awaitTransactionSuccessAsync
@@ -251,15 +222,14 @@ export class ExchangeWrapper { | |||
from: string, | |||
): Promise<TransactionReceiptWithDecodedLogs> { | |||
const params = orderUtils.createMatchOrders(signedOrderLeft, signedOrderRight); | |||
const txHash = await this._exchange.matchOrders.sendTransactionAsync( | |||
const txReceipt = await this._exchange.matchOrders.awaitTransactionSuccessAsync( |
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.
This is very nice 🎉
/// For testing, we want to emit an event that is | ||
/// not known by the calling contract. | ||
event TestEvent2( | ||
uint256 lorem, |
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 love the lorem ipsum
👍
contracts/utils/test/log_decoding.ts
Outdated
// tslint:disable no-unnecessary-type-assertion | ||
expect((txReceipt.logs[0] as LogWithDecodedArgs<DecodedLogArgs>).args).to.be.deep.equal(expectedEvent); | ||
}); | ||
it('should not event args when no dependencies are passed into wrapper', async () => { |
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.
"should not decode"?
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.
Looks good to me. I'm looking forward to using this stuff!
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.
Looks fantastic!
just a small request then g2g.
await blockchainLifecycle.revertAsync(); | ||
}); | ||
|
||
describe('Decoding Log Arguments', () => { |
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.
It isn't immediately clear from the tests what the behavior is when we do an emitEvent()
and emitEventDownstream()
at once, without downstream artifacts. I assume TestEvent
will turn into a DecodedLogEntry
and TestEvent2
will remain a LogEntry
, but it might be useful to demonstrate it.
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.
Heh I actually had a test for that and removed it. I'll put it back in. 🙏
@@ -583,6 +584,7 @@ export class ERC20TokenContract extends BaseContract { | |||
artifact: ContractArtifact | SimpleContractArtifact, | |||
supportedProvider: SupportedProvider, | |||
txDefaults: Partial<TxData>, | |||
artifactDependencies: { [contractName: string]: ContractArtifact | SimpleContractArtifact }, |
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.
Shouldn't this be named contractDependenciesArtifacts
? You are passing in the artifacts of the dependencies of the contract no? artifactDependencies
made me think these are dependencies of the artifacts -- which I admit is non-sensical.
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 discussed on Slack if there were alternatives to passing the ABIs in the constructor, and agreed this is probably the best way to do this at this time.
One option discussed was to create a standalone module that exports a static mapping of <contract name>: [ ... contract dependencies]
. When instantiating, check this mapping for any default dependencies. We decided that was overkill in this case.
I'm also not super happy with the name abiDependencies
. I think abi
is already overused and confusing. What about contractDependencies
? The type annotation of contractName -> ContractAbi
makes it clear that we are expecting an ABI.
I also have a small nit about introducing new lodash use in abi-gen
. Apart from these two, looks good to me. :)
packages/abi-gen/test-cli/expected-output/typescript/abi_gen_dummy.ts
Outdated
Show resolved
Hide resolved
packages/abi-gen/test-cli/expected-output/typescript/lib_dummy.ts
Outdated
Show resolved
Hide resolved
Thanks @fabioberger @xianny, I appreciate the feedback! To provide more context, the artifacts/abis are dependencies of the wrapper but not necessarily of the underlying contract. Moreover, they’re known by the end user of the wrapper but may not be known to the author of the contract. Here are two examples of when these dependencies are needed by the wrapper: At present these artifacts are used solely to decode logs, although I used more general naming to try and future proof the parameter. That said, it sounds like this naming is too ambiguous and may not be prescriptive enough. What if we go with something like, |
Thanks for the explanation @hysz. I prefer |
… are included/excluded
…m0xArtifactAsync` and `deployAsync`
…downstream events
… + removed lodash depency in contract wrappers
85934f3
to
048e48b
Compare
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.
thanks for the detailed explanation @hysz ! looks good to me :)
Description
The
awaitTransactionSuccessAsync
function in generated contract wrappers will decode logs, but requires ABI definitions to map topics to arguments. To do this we need (i) the abi for the wrapped contract and (ii) the abi for any contracts it calls.This PR introduces a new parameter,
abiDependencies
, to the constructor of generated contract wrappers. This is passed in when we deploy the contract (which instantiates the wrapper):Testing instructions
Types of changes
Checklist:
[WIP]
if necessary.