Fix serialization of Params with set data type - #19267
Merged
Merged
Conversation
uranusjr
reviewed
Oct 28, 2021
Contributor
Author
|
there's a bit of awkwardness with the |
dstandish
marked this pull request as draft
October 28, 2021 16:06
dstandish
marked this pull request as ready for review
October 28, 2021 17:08
uranusjr
reviewed
Oct 29, 2021
uranusjr
previously approved these changes
Oct 29, 2021
This comment has been minimized.
This comment has been minimized.
uranusjr
dismissed
their stale review
October 29, 2021 02:00
Hmm, I think the test failures are related to the change and need to be fixed.
uranusjr
reviewed
Oct 29, 2021
dstandish
marked this pull request as draft
October 29, 2021 07:28
dstandish
marked this pull request as draft
October 29, 2021 07:28
dstandish
force-pushed
the
fix-param-issue
branch
from
October 29, 2021 14:47
1a38d3b to
33ac787
Compare
dstandish
force-pushed
the
fix-param-issue
branch
from
October 29, 2021 15:08
fe97aba to
fc7f4f5
Compare
dstandish
marked this pull request as ready for review
October 29, 2021 15:16
msumit
reviewed
Nov 3, 2021
Contributor
|
lgtm overall. Also nice work in handling the backward compatibility 👍 |
msumit
approved these changes
Nov 3, 2021
kaxil
reviewed
Nov 3, 2021
dstandish
force-pushed
the
fix-param-issue
branch
from
November 3, 2021 20:44
b9818f9 to
01eacb4
Compare
Member
|
@dstandish Can you take a look at the failing tests please |
Contributor
Author
yup will do |
dstandish
commented
Nov 4, 2021
Contributor
Author
|
fyi i updated Param init to check whether the |
kaxil
reviewed
Nov 4, 2021
kaxil
approved these changes
Nov 5, 2021
jedcunningham
approved these changes
Nov 5, 2021
jedcunningham
pushed a commit
that referenced
this pull request
Nov 5, 2021
This is a solution for #19096 Previously, the serialization of params did not run the param value through the `_serialize` function, resulting in non-json-serializable dictionaries. This manifested when a user, for example, tried to use params with a default value of type `set`. Here we change the logic to run the param value through the serialization process. And I add a test for the `set` case. closes #19096 (cherry picked from commit 8512e05)
19 tasks
2 tasks
2 tasks
22 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
This is a solution for #19096
Previously, the serialization of params did not run the param value through the
_serializefunction, resulting in non-json-serializable dictionaries. This manifested when a user, for example, tried to use params with a default value of typeset.Here we change the logic to run the param value through the serialization process. And I add a test for the
setcase.Could def use extra set of eyes on schema definition. btw i added hook for formatting this -- i can do that in separate pr if that's helpful.