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

Support returning [Type, nil] from resolve_type #4130

Merged
merged 1 commit into from Jul 4, 2022

Conversation

rmosolgo
Copy link
Owner

@rmosolgo rmosolgo commented Jul 4, 2022

Fixes #4085

Another option is to call continue_value in this code, which would change the behavior like this:

- { "myUnion" => { "b" => nil } }
+ { "myUnion" => nil }

This would be more like how objects are handle, but it would break some other tests in library. I'm open to it and I'll consider it if requested.

@rmosolgo rmosolgo added this to the 2.0.11 milestone Jul 4, 2022
@rmosolgo rmosolgo merged commit 28bb436 into master Jul 4, 2022
@rmosolgo rmosolgo deleted the nil-object-from-resolve-type branch July 4, 2022 16:08
swalkinshaw added a commit that referenced this pull request Mar 29, 2023
#4130 fixed returning
`[Type, nil]` from a union's `resolve_type`, but it caused a regression
for literal `false` values.

`Schema#resolve_type` had a `if resolved_value` conditional would be false
for `false` values causing it _always_ return a single value (the `resolve_type`).

The runtime's `resolve_type` method would then _always_ return the tuple
version (in non-lazy cases): `[type, value]`. However, since
`Schema#resolve_type` was only returning a single value, the resolved
value would be lost resulting in `[type, nil]` being passed on.

The fix is to remove the `if resolved_value` conditional entirely and
always return the two-value tuple ensuring the original resolved value
is correctly passed along.

Note: the runtime still has a branch to check if the `resolve_type`
value is a tuple or not. The only case where this won't be true is for
lazy resolved types.
swalkinshaw added a commit that referenced this pull request Mar 29, 2023
#4130 fixed returning
`[Type, nil]` from a union's `resolve_type`, but it caused a regression
for literal `false` values.

`Schema#resolve_type` had a `if resolved_value` conditional would be false
for `false` values causing it _always_ return a single value (the `resolve_type`).

The runtime's `resolve_type` method would then _always_ return the tuple
version (in non-lazy cases): `[type, value]`. However, since
`Schema#resolve_type` was only returning a single value, the resolved
value would be lost resulting in `[type, nil]` being passed on.

The fix is to remove the `if resolved_value` conditional entirely and
always return the two-value tuple ensuring the original resolved value
is correctly passed along.

Note: the runtime still has a branch to check if the `resolve_type`
value is a tuple or not. The only case where this won't be true is for
lazy resolved types.
rmosolgo pushed a commit that referenced this pull request Mar 29, 2023
#4130 fixed returning
`[Type, nil]` from a union's `resolve_type`, but it caused a regression
for literal `false` values.

`Schema#resolve_type` had a `if resolved_value` conditional would be false
for `false` values causing it _always_ return a single value (the `resolve_type`).

The runtime's `resolve_type` method would then _always_ return the tuple
version (in non-lazy cases): `[type, value]`. However, since
`Schema#resolve_type` was only returning a single value, the resolved
value would be lost resulting in `[type, nil]` being passed on.

The fix is to remove the `if resolved_value` conditional entirely and
always return the two-value tuple ensuring the original resolved value
is correctly passed along.

Note: the runtime still has a branch to check if the `resolve_type`
value is a tuple or not. The only case where this won't be true is for
lazy resolved types.
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.

Can't return null values from union resolve_type when using tuples
1 participant