Add test to ensure flows can be deserialized prior to depoy #1397
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.
Thanks for contributing to Prefect!
Please describe your work and make sure your PR:
CHANGELOG.md
(if appropriate)docs/outline.toml
for API reference docs (if appropriate)Note that your PR will not be reviewed unless all three boxes are checked.
What does this PR change?
A user had a situation in which he modified attributes of a task in a way that Core would have prevented if the same arguments were provided at task initialization. Specifically: setting a
max_retries
value without a correspondingretry_delay
. The user then deployed the flow to Cloud. All healthchecks passed, including serialization. However, Cloud (correctly, in this case) rejected the flow as invalid.The issue is that the serialization healthcheck is a cloudpickle serialization check, not a JSON serialization check. In this case, the Flow was indeed a valid Python object -- there was nothing Pythonically "wrong" with assigning max_retries a value (though it would have caused an issue at runtime!). Cloudpickle serialization doesn't call
__init__()
, so it didn't apply the validation logic. JSON deserialization DOES call init(), so it validates that arguments (likemax_retries
andretry_delay
) are appropriately set.In order to avoid this poor user experience, this PR adds a check to make sure that the serialized flow can also be immediately deserialized.
Why is this PR important?
User experience, finding out right away if a flow's serialized form is invalid!