Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADR 32: Typed Events #7474
ADR 32: Typed Events #7474
Changes from 17 commits
330e0ce
85b582f
9adaf97
df6e60d
2fc1cf9
f633046
027995e
8b95d42
6e5e9c1
3bf2ab8
4ca6eef
73688cb
b711a7b
8504398
5e6c32e
64b5ee9
6d48bc1
7b340e1
27442f4
9b3ca99
b3325ff
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Agree, event driven API is very useful for app developers.
That being said, I'm wondering if designing a subscription mechanism for messages (emitted when a
Msg
lands into the blockchain) would solve it in a better way?Msg
s already have a well defined structure and an "url" (type).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.
There does seem to be a lot of redundancy I agree, but events are already used pretty widely in the ecosystem and sometimes communicate things not covered in
Msg
s. For instance a cosmwasm contract could have the side effect of creating a gov proposal, even if theMsg
submitted to the blockchain was just to call a contract.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.
If we go with Msg-based OCAPS (i.e. assuming both ADR031 and ADR033 get merged), this contract would need to send a MsgSubmitProposal, which in turn will emit the corresponding Msg Response.
I'd like to see a use-case in this ADR where a message subscription mechanism is not enough, as I feel ADR031 and ADR033 can get to the same goal in a more elegant way. We could of course still emit events, because of inertia in the ecosystem, but they will be Msg Responses and not typed events.
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 don't think it's just inertia. Does the cosmwasm use case I mentioned above not seem like something unaddressed by
Msg
responses?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.
Possibly with ADR 033 though, we can capture all of the nested
Msg
s that get sent between different modules and maybe it would have the same result...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.
Can someone link to ADR 33? I don't see the open PR...
Also this is a basic improvement to the current event system that is really low impact. It can be additive with other changes, but will make using the tendermint websocket easier for developers. I would also personally like this change for the relayer and the IBC code specifically.
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.
One thing that isn't covered by
Msg
subscription is the emission of events inEndBlock
. See the band protocol example: https://blog.cosmos.network/guide-to-building-defi-using-band-protocol-oracle-and-cosmos-ibc-fa5348832f84There 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.
To clarify, these typed events are designed for external/client-side applications? I think it is very good to provide the best event support possible for them... working on consuming this since early 2018 and it has been rough getting much working out of it... almost never well tested or structured. I am very happy for such improvements.
If you are saying, as I believe some are interpreting, of using Events to communicate between modules in the SDK, then I have some hesitation. Not that it is bad, but adds a lot of potentials that need to be considered.
Anyway the use of "SDK apps" can be interpretted two ways. I would prefer "SDK modules" or "SDK clients" (and we have strong support for such clients in JS/TS... not just Go.
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.
@jackzampolin , could you add a note that subscription to
Msg
doesn't solve all use cases?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.
@ethanfrey this work would also allow for better TS/JS libs around events as well.
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.
EventSubmitProposal
is typically a use-case where I believe a Msg response makes more sense. With ADR031+ADR033, I would call this structMsgSubmitProposalResponse
.Could we maybe put an example that's not directly a response from a Msg?
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 think
MsgSubmitProposalResponse
would only includeproposal_id
in ADR 031. There's overlap for sure. CombiningMsgSubmitProposal
+MsgSubmitProposalResponse
would give the same info but is maybe more cumbersome.