Is your feature request related to a problem? Please describe.
In production, many chargers will include extra fields or omit required fields. This is generally a bug on the charger, and building the server to be flexible (especially of additional fields) is important for maintaining operations.
Describe the solution you'd like
- parsing is lenient of extra fields, parsing succeeds if additional fields are present
- additional fields are extracted from the raw payload and stored in a map on the dataclass
- missing fields are also supported via some defaulting mechanism. I don't want to change all the models to have optional fields, that seems like an anti pattern.
Describe alternatives you've considered
We've tried rolling with it as is, and filtering out extra fields in memory before parsing. This kind of thing can be handled on the user side, but library support is better.
Additional context
This is mostly about supporting a wide variety of chargers so that we can handle data that isn't fully spec compliant, but is still processable
Is your feature request related to a problem? Please describe.
In production, many chargers will include extra fields or omit required fields. This is generally a bug on the charger, and building the server to be flexible (especially of additional fields) is important for maintaining operations.
Describe the solution you'd like
Describe alternatives you've considered
We've tried rolling with it as is, and filtering out extra fields in memory before parsing. This kind of thing can be handled on the user side, but library support is better.
Additional context
This is mostly about supporting a wide variety of chargers so that we can handle data that isn't fully spec compliant, but is still processable