ICS4: Event emission Specification #1165
Conversation
AdityaSripal
requested review from
damiannolan,
sangier and
angbrav
as code owners
|
if you could also give an ack on current events spec'ed for |
|
Done! @DimitrisJim |
| sequence: sequence, | ||
| packet: packet, | ||
| timeoutTimestamp: timeoutTimestamp, | ||
| destId: channel.counterpartyChannelId, |
There was a problem hiding this comment.
I see these are defined as bytes in spec atm (for eth side of things where these are a contract address I assume?). Should they be hex encoded too in spec?
There was a problem hiding this comment.
Mmmm this is a good point. In ibc-go this is an alphanumeric string. It feels wasteful to convert that to a hex string only to convert it back. Tho it is possible that other implementations use bytes that do not decode to ASCII characters.
What do you think @gjermundgaraba ?
There was a problem hiding this comment.
It is a string in Solidity (which is technically dynamic bytes array), but I don't think we suffer too much on this. Unless it was a fixed-length byte array I don't think we would save much on Solidity.
| // Event Emission | ||
| emitLogEntry("sendPacket", { | ||
| // Event Emission for send packet | ||
| emitEvents("send_packet", { | ||
| sourceId: sourceChannelId, |
There was a problem hiding this comment.
Is there any particular reason why we use sourceId here rather than sourceChannelId? I don't care too much either way, but why not use the same names as the packet structure?
| sequence: sequence, // value is string in decimal format | ||
| timeoutTimestamp: timeoutTimestamp, // value is string in decimal format | ||
| payloadLength: len(payloads), // value is string in decimal format | ||
| // include first payload data in events if there is only one payload |
There was a problem hiding this comment.
Does that mean that if this is a multi-payload packet, these need to be empty strings?
There was a problem hiding this comment.
I think we can still fill these in.
There was a problem hiding this comment.
Right, yes because you would check the length to find out if there should be more to look for.
| // reconstructed by relayers | ||
| for i, payload in payloads { | ||
| emitLongEntry("send_payload", { | ||
| sourceId: sourceChannelId, |
There was a problem hiding this comment.
Same question as above regarding naming differences
| emitLogEntry("writeAcknowledgement", { | ||
| sequence: packet.sequence, | ||
| emitEvents("write_acknowledgement", { | ||
| sequence: packet.sequence, // value is string in decimal format |
There was a problem hiding this comment.
nit/question: Curious about the use of the word "decimal" here. I immediately think of a number with some kind of precision. Would it be simpler to say integer?
Also, what is the reason for using string-formatted numbers here?
There was a problem hiding this comment.
I mean that the string is base10 as opposed to hexadecimal or something else.
This is assuming the event system is a <string, string> attribute system.
| @@ -784,14 +825,49 @@ function writeAcknowledgement( | |||
| // Note that the event should be emitted by this function only in the asynchrounous ack case. Otherwise the event is emitted during the onReceive | |||
| packet=getPacket(destChannelId,sequence) | |||
| if(packet!=nil){ | |||
| emitLogEntry("writeAcknowledgement", { | |||
| sequence: packet.sequence, | |||
| // construct acknowlegement event by concatenating each app acknowledgment together with a "/" delimiter | |||
There was a problem hiding this comment.
Since we emit separate events for multiple payloads, could we not do the same here? Is it because it would be simpler for an event handler to always have to deal with a single writeAcknowledgement event per packet?
There was a problem hiding this comment.
We could do this yes. Think I just did this before thinking about the payload case
Emit events for relayers to construct the packet messages