Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
0.9.1, 0.9.2
-
None
-
None
Description
Repeatedly in the past we've got hit by the following problem with using Thrift from Java:
Consider the following simple model:
enum Colour {
red,
blue
}
struct Product {
string sku;
map<Colour, i32> inventory;
}
In our scenario Service A uses this version of the model. Service B uses a
newer version in which a new enum value "green" has been introduced.
Under the following circumstances...
1) B serializes a product in which an inventory entry is contained with a key of green.
2) A deserializes this product. As it does not know of green yet, the
problematic map key is deserialized as null.
3) A serializes the product again
...a NullPointerException is thrown because null map keys are not handled gracefully.
Many times thrift handles these kinds of version mismatches more graceful, so I would appreciate this to be bug 
.
I think it would be appropriate to omit the offending entry from the map during deserialization, because as the key is unknown the whole entry is arguably pointless.