feat(replays): Leave non-critical fields as generic "Value" types #1702
Conversation
|
@iker-barriocanal Type safety is not a requirement. We have no desire to validate the payload. We're parsing and stripping PII. If we could guarantee no PII then we would not parse this at all. |
|
@iker-barriocanal The problem we're facing is that these values may not be well typed in their implementation. It's better to just accept values we don't care about and let our javascript implementation sort out the quirks. |
|
@cmanallen is there a desired target type for all these fields? For example, SDKs might send an identifier as either string or number, but you always stringify it for your backend (can follow up with an example). That way, you reduce the burden on all other systems that touch this data to handle all permutations or edge-cases. We noticed with the event protocol in the past that leaving completely untyped and not enforcing constraints early on leads to much added complexity down the road. If you need an urgent bugfix, we can still merge this. A conversation on the role of normalization and schemas will definitely take a little more time. |
No. The contract is maintained between the recording component and the player component. Both are open source projects outside the control of Sentry. The rrweb maintainers bear the burden of their schema definitions. |
|
In that case it would probably be better if we define no schema at all and use a plain |
|
Let's leave the schema in place for now. I'll review the generic schema implementation independently. |
) closes: getsentry/replay-backend#239 Leaves non-critical fields as generic `Value` types which can be re-serialized later without consequence to PII scrubbing.
closes: https://github.com/getsentry/replay-backend/issues/239
Leaves non-critical fields as generic
Valuetypes which can be re-serialized later without consequence to PII scrubbing.