Handle Uuid FullLoader with yaml de/serializer #310
+15
−2
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 #221, the yaml loaders are changed to UnsafeLoader to solve the problem after new (at that time it is new, it has been three years now) PyYAML, by default it won't de/se customize type.
The changes in #221 touched two things, one was the deserializer for bundle type which the change is needed, as detail discussion in aiidateam/aiida-core#3709 where issue was originally manifested.
But the change of using
UnsafeLoader
also made for the kiwipy message decoder, which is not necessary. The reason that thermq.test_communications:test_launch_nowait
test was hanging is that the response ack message from channel is a PID which has typeuuid.UUID
. It is not a basic type that covered by yaml decoder.The more fine tuning change I think should be just adding the UUID representer and constructor explicitly.
Here I also explicitly use
UnsafeLoader
instead ofLoader
which are the same, but Loader is for backward compatibility andUnsafeLoader
is the new API and give the information that it is unsafe operation.@superstar54 @giovannipizzi, for the workgraph the
unsafe_deserializer
is what wrapped for the similar purpose I guess. So I'll let you think about whether you can do the same thing by adding all customize types into the range for the yaml deserializer to avoidunsafe
keyword. I think for an API exposed to end user, it should never "unsafe" in terms of data/computer security, but the "unsafe" is left for developers to find out where in the source code that cause memory issue or potential security issue.