reports of duplicated audio recordings from audio surveys.

biblicabeebli commented 5 months ago

We have some code that recovers potentially-lost recordings, maybe something changed in the shared code when we added ambient audio.

TODO:

does this occur with both compressed and uncompressed audio types
does this occur if you wait a super long time (like a minute) after finishing the recording to submit it.
does this occur if you wait a super short time after finishing the recording to submit it.

biblicabeebli commented 4 months ago

This bug may be fixed is 3.6.0, we are still testing this, due to the source report of this bug coming from a live study we were tracking this internally - but this is only about a day of (anything-to-report) debugging behind.

I ended up writing some code that let me go day-by-day through the survey push notifications a participant would experience.

I think I got the bug, it is dumb. It's some interaction with the ~back button~ back stack. (Standard developer caveat: there is A bug that does something like what is reported here, I think it is the reported bug, it could potentially be a different bug. I will refer to this bug as "my bug".) Update: grr-arg - I cannot tell if the bug I found is the bug you are demonstrating, I can only get it to happen with a single survey visible.

TLDR we have a bug somewhere where you can get multiple instances of the main menu "activity" (app screens are called activities in android land). If you have ever done the Android back button/action (it used to be a button, now it's a swipe gesture) inside the app while on the main menu and it "moves you backward" to... the main menu again instead of bumping you to the app's screen. <~ That's the bug I am talking about. (These activities are stored like a stack of paper, the topmost activity is visible and the back button removes the topmost activity.)

~Due to exactly when the triggers to update the list of buttons occurs, if you stack two (or more?) main menus on top of each other and achieve the weird state, that "bottom" main menu that you land on will have an old button layout.~
Update: ok the way the code is constructed it is not exactly the above, the calls to update are appropriately located on the onResume function....
Dismissing the app from the task switcher and reopening it - this fully reloads the main menu activity and the list of survey buttons reflects reality.
update 1: I made a version of the app where there is a ~checker that updates the survey buttons on the main menu once a second so that they match the state of notifications. Even on this version of the app I can replicate my bug.

Directions to reproduce my bug - works every time:

clear out any existing buttons (by taking surveys or using the special debug menu button, doesn't matter)
go click the button on the participant page to send a notification , the buttons update.
tap the single survey button, take the single survey, press the done/submit button.
main menu is displayed empty.
do the back action, the main menu will be dismissed revealing... another main menu but this time with the button for the survey you just took.
Update: ok I have confirmed that this bug is reproducible on an older version of the app. Cool. Cool cool.
Update: And now I have confirmed that when you have 2 surveys and take one... it does not do the bug. And also backgrounding and then foregrounding the app refreshes the screen.

biblicabeebli commented 4 months ago

RC2 extends the fix to audio surveys (oversite on my part), and changes some functionality that Probably won't have an effect.

biblicabeebli commented 3 months ago

I believe I tracked down the issue, here is my developer note in the changelog. Will post an RC3 later today.

Fixes a bug where a survey notification would be instantly reinstantiated after the survey
was completed if the survey had no weekly scheduled times and was triggered via the internal
app timers. This could occur on relative and absolute schedule surveys because when the
"buffer" of "this week's surveys" encounters an absolute or relative scheduled survey with
nothing in the next week... it sends an appropriately empty schedule listing for that survey.
In this situation the app does not update the tracked "trigger alarm time" timestamp when a
survey is completed, so a survey trigger "in the past" was always found when the app checked.

biblicabeebli commented 3 months ago

Confirmed that that was the bug. 3.6.0 is pushed.

onnela-lab / beiwe-android

reports of duplicated audio recordings from audio surveys. #91