Community Health Toolkit

Different types of errors in feedback docs

While parsing through some feedback docs, I noticed a few different formats that errors take in the docs. Some are classified as errors in a ‘log’ section and have a stack, some are in the ‘log’ section without a stack, and some are just uncaught exceptions in an ‘info’ section. All of the last type that I have seen are pointing to the same line as well. Does each different type mark a different type of error or have some sort of other significance, or are they all just errors caught at different points in the execution? I’ve included a few examples below for reference:

{"_id": “c58dbdd0-2c0a-4a0f-975b-b89eb5d1cd15”, “log”: [
{“level”: “error”, “arguments”: “{“0”:“Execption thrown in JavascriptInterface function: java.lang.SecurityException: Sending SMS message: uid 10095 does not have android.permission.SEND_SMS.; at android.os.Parcel.readException(; at android.os.Parcel.readException(; at$Stub$Proxy.sendTextForSubscriber(; at android.telephony.SmsManager.sendTextMessageInternal(; at android.telephony.SmsManager.sendTextMessage(; at android.telephony.SmsManager.sendMultipartTextMessageInternal(; at android.telephony.SmsManager.sendMultipartTextMessage(; at; at org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native Method); at org.chromium.base.SystemMessageHandler.handleMessage(; at android.os.Handler.dispatchMessage(; at android.os.Looper.loop(; at; “}”}, “_rev”: “1-99a32061a26f5c91d29aa361d76aa8dd”, “info”: {“file”: “”, “line”: 3, “message”: “Uncaught TypeError: Cannot read property ‘scrollIntoView’ of undefined”}, “meta”: {“app”: “medic”, “url”: “”, “time”: “2020-03-08T15:21:24.939Z”, “user”: {“name”: “-----”, “roles”: [”-----”]}, “source”: “automatic”, “version”: “3.4.0”}, “type”: “feedback”}

{"_id": “5f1d8f95-49a2-4029-b78b-e95dce31b25e”, “log”: [{“level”: “error”, “arguments”: “{“0”:“The select2(‘data’) method was called on an element that is not using Select2.”}”}, “_rev”: “1-695249fc918d0c60c5a6362c17a4496e”, “info”: {“file”: “”, “line”: 3, “message”: “Uncaught TypeError: Cannot read property ‘scrollIntoView’ of undefined”}, “meta”: {“url”: “”, “time”: “2019-07-05T18:44:39.756Z”, “user”: {“name”: “------”, “roles”: ["------"]}}, “type”: “feedback”}

{"_id": “dae23241-fd50-42cb-93b0-5b325886dd74”, “log”: [], “_rev”: “1-8390c6a0d939f54c552e012a4987a440”, “info”: {“file”: “”, “line”: 3, “message”: “Uncaught InvalidStateError: Failed to execute ‘index’ on ‘IDBObjectStore’: The transaction has finished.”}, “meta”: {“url”: “”, “time”: “2019-07-05T12:04:00.056Z”, “user”: {“name”: “-----”, “roles”: ["-------"]}}, “type”: “feedback”}

1 Like

Hi @Ethan .

The log property stores the last 20 lines that were written to console in an attempt to give more context about what may have been going on at the time. When this is empty (as in your third example) it’s probably because the error happened immediately at startup and nothing had been written to the console yet. That specific error looks to be a DB issue which can happen early in the app loading workflow so it’s logical that the log would be empty.

Because the log has the last 20 lines the ones with stack traces may in fact be completely unrelated to the error that this doc represents.

The most important property to look at is the message property which contains the information about this specific error and may or may not contain the stack that was caught.