kpi is the (frontend) server for KoboToolbox. It includes an API for users to access data and manage their forms, question library, sharing settings, create reports, and export data.
If the exception weren't caught, we'd get a stack trace with local variables in Sentry. Instead, we get src, id_string, uid, _msg, and warnings (and _msg isn't even shown?): https://sentry.kbtdev.org/kobo/kpi-backend/issues/2837/.
I think this is basically the same situation as https://github.com/kobotoolbox/kpi/issues/1705, but we'll have to figure out whether some of the exceptions that could be raised here have to do with user error, e.g. invalid XLSForms.
For now, I'll try calling FormPack.to_xml() manually inside the Django shell to get a useful traceback.
Copying my gripe from https://github.com/kobotoolbox/kpi/issues/2057#issuecomment-436302676 into a new issue.
@noliveleger, here's an example of how trying to handle exceptions gracefully can make debugging much harder: https://github.com/kobotoolbox/kpi/blob/550dc439aa9a38fc444ba5745d27be21177b0625/kpi/models/asset.py#L885-L901
If the exception weren't caught, we'd get a stack trace with local variables in Sentry. Instead, we get
src
,id_string
,uid
,_msg
, andwarnings
(and_msg
isn't even shown?): https://sentry.kbtdev.org/kobo/kpi-backend/issues/2837/.I think this is basically the same situation as https://github.com/kobotoolbox/kpi/issues/1705, but we'll have to figure out whether some of the exceptions that could be raised here have to do with user error, e.g. invalid XLSForms.
For now, I'll try calling
FormPack.to_xml()
manually inside the Django shell to get a useful traceback.