Using group notifications combined with HoldingQueue leads to incorrect numTotal

[781flyingdutchman]

Discussed in https://github.com/781flyingdutchman/background_downloader/discussions/418

^{Originally posted by **philitell** November 26, 2024} Hi, i'm trying to use notifications for groups. I have a large number of DownloadTasks within a group (e.g. 80 tasks). Those tasks are all enqueued and i would like to show a notification that says e.g. "25 of 80" with a progress-indicator. The problem is that i'm seeing an notification that gets updated with every status update (when a Task is started and completed). So the notifications shows "0 of 1" - then gets updated to "1 of " - then when the next file is downloaded the notification is updated and shows "0 of 1" again. This happens for all 80 files. What i'm doing wrong? ``` // here is the general initialization/configuration await FileDownloader().ready; final configResult = await FileDownloader().configure( globalConfig: [ (Config.requestTimeout, const Duration(seconds: 100)), (Config.checkAvailableSpace, 500), // NOTE: queue and sets the constraints maxConcurrent to 3, maxConcurrentByHost to 2, // and maxConcurrentByGroup to 1. (Config.holdingQueue, (3, 2, 1)), ], androidConfig: [ (Config.useCacheDir, Config.whenAble), ], iOSConfig: [ (Config.localize, {"Cancel": S.current.stopIt}), ], ); // Register an event listener to process status and progress updates _ref.read(fileTransferTaskStatusUpdateProvider); repositoryLogger.info("Start persistent task tracking"); await FileDownloader().trackTasks(); repositoryLogger.info("Check for events that happened while the app was in the background"); await FileDownloader().resumeFromBackground(); .... // this is my notification configruation which is created right before the tasks of the current group are enqueued (i'm NOT using downloadBatch because is need to to persistent task tracking as well) FileDownloader().configureNotificationForGroup( groupIdentifier, running: const TaskNotification("{numFinished} von {numTotal}", "Fortschritt: {progress}"), complete: const TaskNotification("Abgeschlossen", "{numTotal} Dateien heruntergeladen"), error: const TaskNotification("Fehler", "{numFailed}/{numTotal} fehlgeschlagen"), progressBar: true, groupNotificationId: "notification_$groupIdentifier", ); ```

[781flyingdutchman]

Note to self, re Android:

• Caused by GroupNotification for a task only getting created (using GroupNotification.update) when a task is enqueued with the WorkManager, not when the task is enqueued with the HoldingQueue. As a result, only WorkManager tasks are included in the numTotal count, which undercounts the total enqueued for the group. Not sure I fully understand why the number eventually doesn't go beyond the maxConcurrent value though - likely because the groupNotification object gets destroyed when numFinished == numTotal but I would have expected new tasks to get added to drive numTotal up.
• Check the hasFinished method which currently returns true if all tasks are not running. I think it needs to include a check on enqueued to avoid marking the group as finished prematurely.
• Solution is to create the GroupNotification task entry when the task is enqueued with the HoldingQueue, by calling the updateNotification method of the NotificationService
• Issue is that updateNotification requires a TaskWorker, which is why we need to use the UpdateNotificationTaskWorker to update the notification. Current implementation is built to update a notification when the task is not in the WorkManager (e.g. after fail with no retries left) and does not consider groupNotifications (this itself may be a bug) so we need to add that
• When using a scheduled task to update the notification when it is enqueued with the HoldingQueue, we run the risk that it is executed out of order (e.g. the 'enqueue' update gets executed after the task has already started running, or has completed). Because only enqueue updates are scheduled, we can reasonably prevent this by only recording the enqueue status if the task was not already present in the list/set of tasks related to the groupNotification, and ignoring it otherwise. We may have to make sure the GroupNotification object isn't destroyed immediately upon completion of the last task, in case the out of order enqueue update arrives after that (which would cause it to re-create the groupNotification object and create a new notification).
• If tasks in the holding queue are cancelled, we need to schedule a canceled notification similar to how we schedule a enqueued notification, to make sure the numFinished count of the groupNotification remains in sync

Haven't checked iOS but suspect similar issue