Skip to content

Don't retry tasks when running in foreground #6900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 23, 2025
Merged

Don't retry tasks when running in foreground #6900

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5f78789
Don't retry tasks when running in foreground
seadowg Sep 21, 2025
9a6647e
Use unique ID for form updates notification
seadowg Sep 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions async/src/main/java/org/odk/collect/async/TaskSpecWorker.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,12 +61,12 @@ class TaskSpecWorker(

try {
val completed =
taskSpec.getTask(applicationContext, stringInputData, isLastUniqueExecution(taskSpec)) { isStopped }.get()
taskSpec.getTask(applicationContext, stringInputData, foreground || isLastUniqueExecution(taskSpec)) { isStopped }.get()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should always count a foreground task as the last execution so that jobs like SyncFormTaskSpec switch to the behaviour they would use in that mode (like notifying about errors).

val maxRetries = taskSpec.maxRetries

return if (completed) {
Result.success()
} else if (maxRetries == null || runAttemptCount < maxRetries) {
} else if (!foreground && (maxRetries == null || runAttemptCount < maxRetries)) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't want to retry when running in the foreground: it doesn't fit with the idea of having more immediate results/feedback, and it also could cause errors (foreground services should not be started in the background).

Result.retry()
} else {
Result.failure()
Expand Down
2 changes: 1 addition & 1 deletion ...p/src/main/java/org/odk/collect/android/formlists/blankformlist/BlankFormListViewModel.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -211,7 +211,7 @@ class BlankFormListViewModel(
private const val SYNC_NOTIFICATION_CHANNEL = "form_updates"
private const val SYNC_NOTIFICATION_CHANNEL_NAME = "Form updates"

private const val SYNC_NOTIFICATION_ID = 1
private const val SYNC_NOTIFICATION_ID = 3
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like we've made an assumption in the code base that notifications are identified by their ID and their channel. In fact, they are only identified by ID, so this should be unique.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you elaborate on this? Why 3? What was the issue here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is 1, it has the same ID as the error notification (FORM_SYNC_NOTIFICATION_ID) so the error gets cleared when the foreground service hides its notification. We're going to want to work out a centralized source for these IDs, but I wanted to leave that for once we've got tests (#6902).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're going to want to work out a centralized source for these IDs

Yes, this would be important to make it clear. Will that be added to #6902 or a separate issue?

Copy link
Member Author

@seadowg seadowg Sep 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add that to #6902. Right now it's just failing tests (one of which drives out this change). That PR will be the master version of these changes.


private fun getSyncTag(projectId: String): String {
return "match_exactly_foreground:$projectId"
Expand Down