Closed
Description
Relates to #1420 but can be done standalone.
The IUnknownPropertiesConsumer implementation today is different than expected, we can either fix it or remove it as the 'unknown' map that this implementation generates is usually dropped during ingestion.
Not all protocol classes accept non-mapped fields, but we implement IUnknownPropertiesConsumer for every protocol class, this should also be addressed.
It's not a high priority issue though because it only affects hybrid SDKs or when one downgrade the SDK and has a cached envelope that has now a field that is unknown.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Relationships
Development
No branches or pull requests
Participants
Activity
bruno-garcia commentedon Jun 15, 2021
Is there a way to do this with the current reflection-based serialization approach? We've been reconsidering vendoring the handful Gson classes needed to do 'manual' serialization/deserialization and drop the Gson dependency. While doing so we could address this issue by keeping unknown json keys into a
Map<>and serializing back into the JSON when a round-trip serialization happens.It will hopefully address #1420 too since we wouldn't depend on Gson.
Another added benefit is to avoid the Gson version conflict that comes up from time to time:
marandaneto commentedon Jun 16, 2021
I believe it's possible to fix with the current implementation, yes, it'd require adapters for every single protocol class probably.
I'd focus on #1420 and fix this issue while doing it, which is win-win, no reflection, no gson, and doing it by hand is easy to survive unknown fields during round trip.
marandaneto commentedon Nov 8, 2021
closed by #1554