fix(storage): prevent transfer work exception

[tylerjroach]

• PR title and description conform to Pull Request guidelines.

We did not have a try/catch around a method that can throw https://developer.android.com/reference/android/database/Cursor#getColumnIndexOrThrow(java.lang.String).

In rare cases (likely db close) a column may not be available. If this happens, we break out of reading the cursor.

See customer issue for more details.

Issue #, if available:
#2840

Description of changes:
See reported issue for details

How did you test these changes?
(Please add a line here how the changes were tested)

Documentation update required?

• No
• Yes (Please include a PR link for the documentation update)

General Checklist

• Added Unit Tests
• Added Integration Tests
• Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[lawmicha]

if we catch and continue, what happens on the next it.moveToNext() ? does it return null and break out? would it be safer to catch and break out?

[tylerjroach]

It would be false the next time and break out itself

[lawmicha]

I think moving the try-catch to include the while(it.moveToNext()) may be safer incase there's a behavior change where it also throws on closed cursor or some other issue

[tylerjroach]

It is not reported to throw: https://developer.android.com/reference/android/database/Cursor#moveToNext()

[tylerjroach]

I went ahead and added a break as looking through cursor code, I couldn't find where cursor count would be reset to 0 when closed, and didn't see moveToNext checking if cursor were open.

[lawmicha]

If we want to swallow all exceptions here, we would need a second catch block for exceptions other than IlllegalStateException

[tylerjroach]

https://developer.android.com/reference/android/database/Cursor#getColumnIndexOrThrow(java.lang.String)

IllegalStateException is the only exception type to be handled here. Since these Android APIs are written in Java, we can trust that the exceptions thrown should only be the ones listed in documentation.

[mattcreaser]

Is this situation worthy of an error long? What is the impact of failing to attach an observer?

[mattcreaser]

Any ideas how this could happen?

[tylerjroach]

Closing this PR as the fix was a bit misguided.

1. The cursor is never closed in the app, so this isn't a closed cursor.
2. getInt is in fact throwing (even though it doesn't say it throws. It's crashing at a native jni layer.
3. Couldn't read at row 912, column 0 means that a row in the db was not able to be read. Column 0 should just be the "_id" column of TransferTable. In research, this type of issue typically appears if we attempt to read column data containing 2+MB of data. This shouldn't be the case here being only the _id. My only other speculation at this time (outside of device bugs outside of our control), is that multithreaded operations hitting the table could be clearing the cursor where row 912 doesn't actually exist at the time we try to read data from it.