Open eric-burel opened 11 months ago
We probably shouldn't delete any user data? Maybe just handle the error better?
@SachaG I was thinking of making this specific "invalid" field a warning rather than a blocking error? Given that having more fields than needed in the response isn't really a big issue later on, just a sign that there is a bug somewhere. What bothers me is that it then blocks the user to keep responding, so anything that let the user keep responding is fine. I feel like in some scenarios we cannot tell which field is wrong anyway, since we only see the whole response object. Eg we can't tell which fields set an "undefined" key accidentally. Or throw an error only in "preview" mode or smth like that so we can detect bug earlier, and then only warn if the survey is published. We could also let the user delete the offending values from the error message but that might be confusing, because wrong values most often are our fault, because of a bug in a component.
When a field produces invalid data, this will trigger a validation error with zod. THe problem is that it can sometimes only be fixed by removing the response.
Instead we could:
It can happen during development when we change a data type, or when the API has changed, when a template is missing etc. and I've seen this bug in prod too so catching this kind of error would be nice.