Please check if the PR fulfills these requirements
[x] The commit messages are descriptive
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[x] An issue has been created for the pull requests. Some issues might require previous discussion.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Modifies the TopicCustomDeserializer to add the plan name to deserialized topics
resolves #549
What is the current behavior? (You can also link to an open issue here)
The current behavior adds plan configurations to the topic, but loses the original plan name. This results in Topic.getPlan() always returning null
What is the new behavior (if this is a feature change)?
This PR modifies the TopicCustomDeserializer to include the plan name in the deserialized topic.
Topics that do not contain a plan continue to use null, rather than an Optional. This was to maintain backwards compatibility with the current interface
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No.
Please check if the PR fulfills these requirements
[x] The commit messages are descriptive
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[x] An issue has been created for the pull requests. Some issues might require previous discussion.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) Modifies the TopicCustomDeserializer to add the plan name to deserialized topics resolves #549
What is the current behavior? (You can also link to an open issue here) The current behavior adds plan configurations to the topic, but loses the original plan name. This results in
Topic.getPlan()always returning nullWhat is the new behavior (if this is a feature change)? This PR modifies the TopicCustomDeserializer to include the plan name in the deserialized topic. Topics that do not contain a plan continue to use
null, rather than an Optional. This was to maintain backwards compatibility with the current interfaceDoes this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) No.
Other information: