Skip to content
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

chore: MsgUpdateClient rename header to client_message #1316

Merged
merged 2 commits into from
May 9, 2022

Conversation

damiannolan
Copy link
Member

Description

  • Renaming header field to client_message on MsgUpdateClient
  • Updating field naming, protodocs, godocs
  • Adding deprecation notices for misbehaviour submission handlers

closes: #XXXX


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

Comment on lines -50 to +51
// header to update the light client
google.protobuf.Any header = 2;
// client message to update the light client
google.protobuf.Any client_message = 2;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure if this was forgotten about or if this was intended to be left as header. If not required we can close this PR or take the deprecation notices to another PR.

My only concern here is that relayers would be required to support both field names simultaneous depending on what version a chain and it's counterparty are running. Afaik hermes queries chains to determine ibc-go versions already but I am not sure if they have had to support such a scenario yet.
Despite this I think we should still be allowed to freely rename such fields for major version releases.

Curious to hear the thoughts of the team! :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question... If needed I can check with Adi and Justin.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe updating the naming should be fine. But we should check with relayers

Copy link
Contributor

@colin-axner colin-axner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. Nice!

Copy link
Contributor

@seantking seantking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yurt

@damiannolan damiannolan merged commit 8f46821 into 02-client-refactor May 9, 2022
@damiannolan damiannolan deleted the damian/rename-header-to-clientmsg branch May 9, 2022 15:19
oshorefueled pushed a commit to ComposableFi/ibc-go that referenced this pull request Aug 9, 2022
* updating MsgUpdateClient to use client_message field in favour of header

* updating clis, field naming, and adding deprecation notices
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants