feat(toolkit-lib)!: generic messages do not have a code #526
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.
In the original RFC we had introduced the concept of "standard" messages for which no backwards compatibility rules won't apply. In the first developer preview release of
toolkit-lib
this was implemented as message with a code ending in0000
being consider "standard" (or "default") and other messages.With the experience from the developer preview, we have found this way to handle the distinction slightly confusing and putting comparatively complicated work on the user (they need to know and check for the code ending in
0000
). It was also easy to accidentally make a mistake by copy and pasting the message code and not noticing it's specialness.Instead, we are now proposing to change this implementation: Messages and requests with a code will be subject to our backwards compatibility guarantees and can be relied upon by integrators. Standard messages will no longer have a code and must be treated purely informational. Note that all requests and any messages with a payload will always have a code. However some coded messages might not currently have a payload (but may in future according to our backwards compatibility rules).
This PR reflects these changes and updates the message registry with the respective documentation.
BREAKING CHANGE: The
code
field on messages is now optional. All messages with a code are subject to our backwards compatibility guarantees and can be relied upon by integrators. Messages that previously had a "default code" ending in0000
no longer have a code and must be treated purely informational. Requests and messages with a payload are always coded.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license