Thursday, August 22, 2024
1 change · saas-17.4
Enhancements to existing features
Import failures now show less misleading messages when a file cannot be read, helping users understand that the issue may be with the uploaded file rather than a missing system component. Administrators also get more detailed logs to diagnose failures, and the import process avoids repeating the same failed read attempts unnecessarily.
Original PR description
Previous error handling completely suppresses information on failure making it very hard to understand what failed, and furthermore provides confusing messages to the user as a `read_file` failure…
Previous error handling completely suppresses information on failure making it very hard to understand what failed, and furthermore provides confusing messages to the user as a `read_file` failure which is not caught by a bypass (`ValueError` or `ImportValidationError`) will lead to the not just generic but actively misleading > Unable to load "ext" file: requires Python module "soandso" even though the preview / import failed because e.g. the user sent a corrupted file of some sort. Keep the bypasses as direct end-user information, but provide a less misleading error in case of read failure, while logging *with traceback* so administrators can get more insight into the issue (this we may want to roll back in the future). Also avoid trying every single option if reading fails, e.g. if the file has an xlsx extension and the client told us it's an xlsx file and `guess_mimetype` agrees it's an xlsx file, if the first one fails there is no need to try to other two, because that's just calling `_read_xlsx` three times in a row with the exact same options and content.