Update README on events

This commit is contained in:
Ethan Frey
2020-03-02 15:57:28 +01:00
parent 6f938019ed
commit ecdacd03e3

View File

@@ -21,7 +21,9 @@ A number of events are returned to allow good indexing of the transactions from
Every call to Instantiate or Execute will be tagged with the info on the contract that was executed and who executed it.
It should look something like this (with different addresses). The module is always `wasm`, and `code_id` is only present
when Instantiating a contract, so you can subscribe to new instances, it is omitted on Execute:
when Instantiating a contract, so you can subscribe to new instances, it is omitted on Execute. There is also an `action` tag
which is auto-added by the Cosmos SDK and has a value of either `store-code`, `instantiate` or `execute` depending on which message
was sent:
```json
{
@@ -31,6 +33,10 @@ when Instantiating a contract, so you can subscribe to new instances, it is omit
"key": "module",
"value": "wasm"
},
{
"key": "action",
"value": "instantiate"
},
{
"key": "signer",
"value": "cosmos1vx8knpllrj7n963p9ttd80w47kpacrhuts497x"
@@ -60,28 +66,19 @@ provide a initial balance in the same `MsgInstantiateContract`. We see the follo
"key": "recipient",
"value": "cosmos18vd8fpwxzck93qlwghaj6arh4p7c5n89uzcee5"
},
{
"key": "amount",
"value": "100000denom"
}
]
},
{
"Type": "message",
"Attr": [
{
"key": "sender",
"value": "cosmos1ffnqn02ft2psvyv4dyr56nnv6plllf9pm2kpmv"
},
{
"key": "amount",
"value": "100000denom"
}
]
}
]
```
This is actually not very ergonomic, as the "sender" (account that sent the funds) is separated from the actual transfer as two separate
events, and this may cause confusion, especially if the sender moves funds to the contract and the contract to another recipient in the
same transaction. However, this format comes from `x/bank`, so we would have make a few more changes to our cosmos-sdk fork to simplify this.
Finally, the contract itself can emit a "custom event" on Execute only (not on Init).
There is one event per contract, so if one contract calls a second contract, you may receive
one event for the original contract and one for the re-invoked contract. All attributes from the contract are passed through verbatim,
@@ -130,18 +127,13 @@ was executed (which always appears, while 2 is optional and has information as r
"key": "recipient",
"value": "cosmos18vd8fpwxzck93qlwghaj6arh4p7c5n89uzcee5"
},
{
"key": "amount",
"value": "5000denom"
}
]
},
{
"Type": "message",
"Attr": [
{
"key": "sender",
"value": "cosmos1zm074khx32hqy20hlshlsd423n07pwlu9cpt37"
},
{
"key": "amount",
"value": "5000denom"
}
]
},
@@ -169,6 +161,10 @@ was executed (which always appears, while 2 is optional and has information as r
"key": "recipient",
"value": "cosmos14k7v7ms4jxkk2etmg9gljxjm4ru3qjdugfsflq"
},
{
"key": "sender",
"value": "cosmos18vd8fpwxzck93qlwghaj6arh4p7c5n89uzcee5"
},
{
"key": "amount",
"value": "105000denom"
@@ -182,6 +178,10 @@ was executed (which always appears, while 2 is optional and has information as r
"key": "module",
"value": "wasm"
},
{
"key": "action",
"value": "execute"
},
{
"key": "signer",
"value": "cosmos1zm074khx32hqy20hlshlsd423n07pwlu9cpt37"
@@ -195,6 +195,11 @@ was executed (which always appears, while 2 is optional and has information as r
]
```
A note on this format. This is what we return from our module. However, it seems to me that many events with the same `Type`
get merged together somewhere along the stack, so in this case, you *may* end up with one "transfer" event with the info for
both transfers. Double check when evaluating the event logs, I will document better with more experience, especially when I
find out the entire path for the events.
## Messages
TODO