Skip to content
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.

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

Issue with WorkManager Periodic Task Scheduling #538

Open
shubham0809200 opened this issue Feb 19, 2024 · 6 comments
Open

Issue with WorkManager Periodic Task Scheduling #538

shubham0809200 opened this issue Feb 19, 2024 · 6 comments

Comments

@shubham0809200
Copy link

Issue with WorkManager Periodic Task Scheduling

Description

I encountered an issue with WorkManager while scheduling a periodic task with a 2-hour interval and a constraint that the network should be available. Here's the scenario:

  1. The periodic task was initially scheduled for execution at 1:00 AM. which went well
  2. I turned off the network connection until 4:00 AM, causing the task to miss its scheduled execution at 3:00 AM
  3. Due to the unavailability of the network, the task was executed later than expected, at 4:00 AM.
  4. Subsequently, instead of maintaining the 2-hour interval from the last executed task, the next execution occurred at 6:00 AM.

Expected Behavior

The periodic task should maintain its scheduled interval of 2 hours, irrespective of delays caused by network unavailability. In the scenario described above, the task should have been executed at 3:00 AM and then at 5:00 AM, as per the scheduled interval.

I understand the scenario of why it wasn't able to run at 3:00 AM but it should have gone off at 5:00 AM as per its schedule.

I have provided my code for reference the the end of this issue.

Note: If there are any available solutions or recommendations to address this scenario, I would greatly appreciate any assistance or guidance provided. Thank you.

CODE

Workmanager().registerPeriodicTask(
  "backupData",
  "backupData",
  frequency: Duration(hours: 2),
  initialDelay: timeDuration,
  constraints: Constraints(
    networkType: NetworkType.connected,
  ),
  backoffPolicy: BackoffPolicy.linear,
  existingWorkPolicy: ExistingWorkPolicy.replace,
  outOfQuotaPolicy: OutOfQuotaPolicy.run_as_non_expedited_work_request,
  backoffPolicyDelay: Duration(seconds: 10),
);
@prabhakar1992
Copy link

@ened I have also got an issue in workmanager, periodic task not triggered when app is in killed state.

@sinhpn92
Copy link

I have the same issue. Did you solve @prabhakar1992 @shubham0809200 ?

@shubham0809200
Copy link
Author

I have not been able to find a solution for the problem.

@sinhpn92
Copy link

sinhpn92 commented Jul 30, 2024

I have not been able to find a solution for the problem.

I checked by running the command e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"workmanager.background.task"]. However, both the predict and progress tasks only run for about 30 seconds and then stop. They are not running as true long-running tasks. When I tested it in practice, by building a profile for my phone, I noticed that when I plugged in the charger and wasn't using it, the progress task started. But it stopped after running for just 15 seconds. I am not sure if this is an issue with iOS. Do you use any alternative libraries or solutions for this?

@shubham0809200
Copy link
Author

I would suggest that you implement a non-removable notification to make sure the user knows that the app is working on a background task.

I guess as the task is running in the background, which might be causing Android/iOS to terminate the process for security reasons. if you give a notification it will ensure that the user is aware of the process

@FaFre
Copy link

FaFre commented Mar 4, 2025

You set constraints to network required, that's what caused the delay:

constraints: Constraints(
    networkType: NetworkType.connected,
  ),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants