Crash when clicking "Collect data" again in recently added geometry

[jo-spek]

Describe the bug

After having recorded a new site in my survey that does not require anything else but recording a geometry (no further questions, no photo demanded), there is a white pane at the bottom of my screen with the record's name and a green button "Collect data". If I click that button, the app crashes. This does not happen in another survey, where I can answer additional survey questions about a recorded item that I have previously skipped when I click "Collect data".
Happened on Xiaomi Poco X3 with Andoird 12 SQK1.211019.001.

To Reproduce
Steps to reproduce the behavior:

1. Create a new survey with nothing but one job: To walk or draw the perimeter.
2. Draw a perimeter, give it a name and save.
3. In the white pane with the item's name, click the green "Collect data" button again (don't swipe to the right to collect data for a new selection site, that works alright.)
4. Crash.

Expected behavior
I don't really know. Probably not crash. Rather have the "Collect data"-button greyed out.

Actual behavior
Button is there and clickable and triggers a crash of the application.

Screenshots

[shobhitagarwal1612]

Pulled the stacktrace from crashlytics:

Fatal Exception: java.util.NoSuchElementException: Collection contains no element matching the predicate.
       at com.google.android.ground.ui.datacollection.DataCollectionViewModel.getTaskSequence(DataCollectionViewModel.kt:403)
       at com.google.android.ground.ui.datacollection.DataCollectionViewModel.getTaskSequence$default(DataCollectionViewModel.kt:314)
       at com.google.android.ground.ui.datacollection.DataCollectionViewModel.getPositionInTaskSequence(DataCollectionViewModel.kt:300)
       at com.google.android.ground.ui.datacollection.DataCollectionViewModel.getTaskPosition(DataCollectionViewModel.kt:343)
       at com.google.android.ground.ui.datacollection.DataCollectionViewModel.<init>(DataCollectionViewModel.kt:151)
       at com.google.android.ground.DaggerGroundApplication_HiltComponents_SingletonC$ViewModelCImpl$SwitchingProvider.get(DaggerGroundApplication_HiltComponents_SingletonC.java:1478)
       at dagger.hilt.android.internal.lifecycle.HiltViewModelFactory$2.createViewModel(HiltViewModelFactory.java:132)
       at dagger.hilt.android.internal.lifecycle.HiltViewModelFactory$2.create(HiltViewModelFactory.java:103)
       at dagger.hilt.android.internal.lifecycle.HiltViewModelFactory.create(HiltViewModelFactory.java:170)
       at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:184)
       at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:150)
       at androidx.lifecycle.ViewModelLazy.getValue(ViewModelLazy.kt:53)
       at androidx.lifecycle.ViewModelLazy.getValue(ViewModelLazy.kt:35)
       at com.google.android.ground.ui.datacollection.DataCollectionFragment.getViewModel(DataCollectionFragment.kt:49)
       at com.google.android.ground.ui.datacollection.DataCollectionFragment.onViewCreated(DataCollectionFragment.kt:78)
       at androidx.fragment.app.Fragment.performViewCreated(Fragment.java:3147)
       at androidx.fragment.app.FragmentStateManager.createView(FragmentStateManager.java:588)
       at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:272)
       at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1943)
       at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:1845)
       at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:1782)
       at androidx.fragment.app.FragmentManager$5.run(FragmentManager.java:565)
       at android.os.Handler.handleCallback(Handler.java:938)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loopOnce(Looper.java:210)
       at android.os.Looper.loop(Looper.java:299)
       at android.app.ActivityThread.main(ActivityThread.java:8319)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:556)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1038)

[gino-m]

@shobhitagarwal1612 @sufyanAbbasi Do you have bandwidth to take this one on in the next week or so?

[shobhitagarwal1612]

I can take a first pass

[gino-m]

Thank you, @shobhitagarwal1612

[shobhitagarwal1612]

val startIndex = tasks.indexOf(tasks.first { it.id == (startId ?: tasks[0].id) })

The error is happening at line tasks.first { ... }

It is not able to find a task from the list with matching task id.

[shobhitagarwal1612]

@jo-spek Are you able to reproduce this consistently? I tried reproing it but wasn't successful.

[shobhitagarwal1612]

From crashlytics, I can see that it has happened 14 times in total for 3 different users.

[gino-m]

@jo-spek Can you please share the URL of the survey in question in private (by email)?

[jo-spek]

@jo-spek Can you please share the URL of the survey in question in private (by email)?

I added you as a survey organizer. The name of the survey is "Test_June2024".

[gino-m]

val startIndex = tasks.indexOf(tasks.first { it.id == (startId ?: tasks[0].id) })

The error is happening at line tasks.first { ... }

It is not able to find a task from the list with matching task id.

The task in question was a special "add LOI" task - could that have something to do with it?

[sufyanAbbasi]

That's very plausible. Here we construct the tasks list by filtering out the addLoiTask when we're in the predefined geometry flow:

private val tasks: List<Task> =
    if (isAddLoiFlow) job.tasksSorted else job.tasksSorted.filterNot { it.isAddLoiTask }

We determine that we're in this flow when the loidId is null:

/** True iff the user is expected to produce a new LOI in the current data collection flow. */
private val isAddLoiFlow = loiId == null

Which is determined by puling from the savedStateHandler:

private val loiId: String? = savedStateHandle[TASK_LOI_ID_KEY]

Maybe the crash happened because the LOI task is the only task, as mentioned in the repro, so we filtered the task list to empty, which was caught by @shobhitagarwal1612 PR: #2543?

Therefore, to fix this, we can just detect when we've gotten to this state and instead of starting the data collection task, we just throw the error toast: "No more tasks found for this job."

[sufyanAbbasi]

Implemented fix above will show an error message instead of crashing: "This job has no more tasks to complete"