Fix assignability of wrong message type in create #972
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.
The function create() takes an optional initializer object as the second argument. In the object, all fields of the message are optional.
Because of a confusion in the type, it also accepts a message of a different type, as long as the type is assignable (any non-optional property in the target is also present in the source with the same name and type). This results in broken behavior with field presence, where passing a message with unset fields will populate fields in the target with the default value.
Here is an example that demonstrates the issue:
We thought that we prevent this situation with the
$typeName
property, but there is a bug in the internalMessageInit
type that bypasses the type branding.This PR fixes the bug. This is a breaking change because it introduces a compile-time error for a situation that previously compiled without complaints. Since the situation should be very rare, and most likely a bug in itself, we decided to make this change and release it as a bugfix.