You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We do not want to error out and exit if the other sends us messages with null fields or optional fields. eg: the message of type message has an id field that may be set to null. We would like the deserialization of such messages from binary to json be handled leniently.
The text was updated successfully, but these errors were encountered:
warner
changed the title
Handle fields gracefully
Tolerate unrecognized messages/fields gracefully
May 27, 2018
I'll add: in general, the client needs to ignore unrecognized message types and unknown fields inside known messages. This gives us some room for expansion in the future. The unit tests ought to signal an error if we receive unknown messages, but actual runtime code should ignore them. In Twisted I do this with a log.err() call, and the testing framework knows that anything written to the error log should flunk the test. And we test tolerance by asking the testing framework to selectively ignore those error messages in specific tests. I don't know the Rust testing ecosystem well enough to suggest a technique or a library, but I'm sure one is out there somewhere.
Always error during deserialization when encountering unknown fields. When this attribute is not present, by default unknown fields are ignored for self-describing formats like JSON.
So we don't need to do anything here for unknown attributes
For known optional attributes, use Optional<> or #[serde(default)]
For unknown enum variants, use #[serde(other)]. Sadly, there is no way to access that unknown value yet.
There are tricks to store all unmatched keys into a map for dynamic access (I'd have to look it up for an example)
We do not want to error out and exit if the other sends us messages with null fields or optional fields. eg: the message of type
message
has anid
field that may be set tonull
. We would like the deserialization of such messages from binary to json be handled leniently.The text was updated successfully, but these errors were encountered: