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

docs(adr): ADR-044 Guidelines for updating proto defs #9613

Merged
merged 29 commits into from
Aug 2, 2021

Conversation

amaury1093
Copy link
Contributor

@amaury1093 amaury1093 commented Jun 30, 2021

Description

This ADR is to be merged as "DRAFT" status for now, as the details for the "Bumping Protobuf Package Version" section have not been sorted out yet.

This ADR comes from discussion with @webmaster128 and @robert-zaremba about proto updates strategy. We decided to go for an ADR to document our decision for v0.43, and for visibility for other chains doing proto upgrades.

rendered

Closes: #9477
ref: #9446
ref: #9445


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@github-actions github-actions bot added the T: ADR An issue or PR relating to an architectural decision record label Jun 30, 2021
@amaury1093 amaury1093 changed the title adr: ADR-044 Guidelines for updating proto defs docs(adr): ADR-044 Guidelines for updating proto defs Jun 30, 2021
@amaury1093 amaury1093 marked this pull request as ready for review July 5, 2021 14:15

## Abstract

This ADR provides guidelines and recommended practices when updating Protobuf definitions. These guidelines are targeted at module developers.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is a good example where it's halfway between ADR and docs.

Talking with some people, we decided to go with an ADR, as it may provide more visibility for other chain & client developers

Copy link
Contributor

Choose a reason for hiding this comment

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

we decided to go with an ADR, as it may provide more visibility for other chain & client developers

I think this makes sense. I'm wondering if we should also be pointing module developers to this ADR somewhere within the building modules documentation. Adding a line or two that mentions best practices when making updates to Protobuf definitions that points to these guidelines might provide a bit more visibility. For example, I think a simple reference to these guidelines could be added in the Msg Service documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Definitely makes sense to me!


On the other hand, module developers MAY add new fields to Protobuf definitions related to the `Query` service, as the unknown field rejection does not apply to queries.

#### 2. Fields MAY be marked as `deprecated`, and nodes MAY implement a protocol-breaking change for handling these fields.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

In v0.43, we deprecated a field, added some proto comments around it, and introduced a protocol-breaking change related to this field. Do we want to continue doing so in the future?

An argument could be made that protocol-breaking change => proto pkg bump. Or more generally, what's a "breaking change" which would warrant a proto pkg bump?

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to continue doing so in the future?

Ideally, I think we want to avoid this in the future and a protocol-breaking change should warrant a proto pkg bump but this guideline might be worth keeping as a recovery solution should there be a need again.

Copy link
Contributor

@ryanchristo ryanchristo left a comment

Choose a reason for hiding this comment

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

I think this is a solid initial draft. Nice work! A few suggestions and comments.


## Abstract

This ADR provides guidelines and recommended practices when updating Protobuf definitions. These guidelines are targeted at module developers.
Copy link
Contributor

Choose a reason for hiding this comment

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

we decided to go with an ADR, as it may provide more visibility for other chain & client developers

I think this makes sense. I'm wondering if we should also be pointing module developers to this ADR somewhere within the building modules documentation. Adding a line or two that mentions best practices when making updates to Protobuf definitions that points to these guidelines might provide a bit more visibility. For example, I think a simple reference to these guidelines could be added in the Msg Service documentation.

- `UNARY_RPC`: the SDK currently does not support streaming RPCs.
- `COMMENT_FIELD`: the SDK allows fields with no comments.
- `SERVICE_SUFFIX`: we use the `Query` and `Msg` services convention, which don't have the `-Service` suffix.
- `PACKAGE_VERSION_SUFFIX`: some packages, such as `cosmos.crypto.ed25519`, don't use version suffix.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
- `PACKAGE_VERSION_SUFFIX`: some packages, such as `cosmos.crypto.ed25519`, don't use version suffix.
- `PACKAGE_VERSION_SUFFIX`: some packages, such as `cosmos.crypto.ed25519`, don't use a version suffix.

Copy link
Contributor

Choose a reason for hiding this comment

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

Would it make sense to use the version suffix and include the crypto packages in v1? Why was it decided that these packages should not be versioned?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

IIRC we thought these defs should never change. But tbh i'm not opposed to have everything version-suffixed and put crypto as v1.

docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved

On the other hand, module developers MAY add new fields to Protobuf definitions related to the `Query` service, as the unknown field rejection does not apply to queries.

#### 2. Fields MAY be marked as `deprecated`, and nodes MAY implement a protocol-breaking change for handling these fields.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to continue doing so in the future?

Ideally, I think we want to avoid this in the future and a protocol-breaking change should warrant a proto pkg bump but this guideline might be worth keeping as a recovery solution should there be a need again.

@orijbot
Copy link

orijbot commented Jul 13, 2021

Visit https://dashboard.github.orijtech.com?pr=9613&repo=cosmos%2Fcosmos-sdk to see benchmark details.

@amaury1093
Copy link
Contributor Author

Thanks @ryanchristo for the review!

Copy link
Collaborator

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

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

Pre approving

  • let's use more MUST instead of SHALL
  • Let's add "Draft" section to the README and add this ADR there
    Also left few suggestions

docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved

#### 1. `Msg`s SHALL NOT have new fields.

When processing `Msg`s, the SDK's antehandlers are strict and don't allow unknown fields in `Msg`s. This is checked by the unknown field rejection in the [`codec/unknownproto` package](https://github.com/cosmos/cosmos-sdk/blob/master/codec/unknownproto).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shall we be more specific here:

  • we allow new fields for objects which are saved in the store
  • we don't allow new fields for the Msg service arguments

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a bit related to #9613 (comment), so I added a new section

docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
docs/architecture/adr-044-protobuf-updates-guidelines.md Outdated Show resolved Hide resolved
@amaury1093
Copy link
Contributor Author

I'm going to put automerge on. It's been 1+ month, and have 2 approvals from relevant people, so as a draft it should be okay. Can have another round of review with external parties once this goes into "proposed"

@amaury1093 amaury1093 added the A:automerge Automatically merge PR once all prerequisites pass. label Aug 2, 2021
@mergify mergify bot merged commit 56589f1 into master Aug 2, 2021
@mergify mergify bot deleted the am/adr-044-protobuf branch August 2, 2021 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. T: ADR An issue or PR relating to an architectural decision record
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add clear guidelines for allowed Protobuf changes
4 participants