How to stop Dart execution when cancelling a running task?

[devroble]

Hi,

I’m using native_workmanager in my Flutter application and I’m trying to understand how task cancellation works.

When I cancel a task using WorkManager, the native WorkManager task appears to be cancelled, but the Dart code that is already running continues to execute.

For example, if my task is performing a long-running operation:

await longRunningOperation();

and I cancel the WorkManager task while this operation is running, the Dart code doesn’t seem to stop immediately.

Is there a recommended way to:

1. Detect when a running task has been cancelled/stopped?
2. Receive a callback/event in Dart when WorkManager stops the task?
3. Properly terminate or cancel the currently running Dart operation?
4. Is cancellation in native_workmanager expected to behave this way?

I’m particularly interested in knowing whether there is an API such as onTaskStopped or a cancellation token that I should use.

Thanks!

[vietnguyentuan2019]

Hey, good catch — this is a real gap, not you missing something.

Short version: cancelling a task genuinely does NOT stop a running DartWorker callback right now. await longRunningOperation() just keeps going. Reason is Dart itself has no way to preempt/abort a Future thats already running, theres no thread-interrupt equivalent, so whatever gets built here can only be cooperative — your callback has to check "am i still supposed to be running" itself.

Just pushed a fix for it, answering your questions in order:

1. Detect if cancelled → new NativeWorkManager.isTaskCancelled(taskId). Call it from inside your callback whenever you get a chance.

2. Callback/event when stopped → no, it's poll-based not push. Wasn't obvious there was a good way to push it reliably across both platforms without more surface area, so went with polling first. If push would actually matter for your case lmk, could revisit.

3. Terminate the running op → you gotta structure the work so theres a checkpoint to poll from, e.g:

'longSync': (input) async {
  final taskId = input?['__taskId'] as String?;
  for (var i = 1; i <= 100; i++) {
    if (taskId != null && await NativeWorkManager.isTaskCancelled(taskId)) {
      return false; // bail, dont keep working
    }
    await processChunk(i);
  }
  return true;
},

If your op is one big blocking call with no yield points this won't help much — would need to chunk it.

4. Is this expected? — it was the existing (undocumented) behavior, yeah, but not intended to just silently do nothing forever like that. Filed as DartWorker cancellation doesn't stop a running callback (no onTaskStopped / cancellation token) #67, fix in fix(dart-worker): cooperative cancellation via isTaskCancelled (#66) #68.

Also found 2 related bugs digging into this — iOS wasn't even cancelling the actual background task on BGTask expiration (just a no-op stop() call), and Android could leak the dart engine on cancel. Both fixed same PR.

Will be in the next release. Let me know if the polling shape is awkward for what you're doing and I'll think about alternatives.

[devroble]

Thanks for the fast implementation.

I’d strongly prefer putting the cancellation responsibility in the framework rather than requiring every app developer to implement their own cancellation mechanism.

[devroble]

@vietnguyentuan2019 Do you have any ideas?

[vietnguyentuan2019]

Fair point, get it.

So automatic cancel isn't impossible — it's already how this lib handles timeout today, just force-disposes the whole engine and kills whatever's running. The reason cancel doesn't do the same thing is that's a hard kill, no finally, no chance to close a file handle or finish a partial write. Yanking that mid-op felt worse than what you've got now.

Been going back and forth on an opt-in "just kill it" mode, or maybe a grace period — poll for a few secs, then kill regardless if it hasn't stopped. Haven't landed on one yet tho.

Not trying to punt this back on you, still chewing on it. Will update here once I've actually got somthing instead of thinking out loud.

[devroble]

Have a look at here. Also, make sure to consider the different lifecycle scenarios, especially what happens when the application is killed or terminated by the system while the background task is running.

[Rikoshu]

I don’t think that calling "await NativeWorkManager.isTaskCancelled(taskId)" alone will help if a job has been scheduled with ExistingTaskPolicy.replace.
On Android, a running job is cancelled and immediately restarted. Therefore, in this case, the check may still return false.

[vietnguyentuan2019]

quick update — v1.8.0 just shipped (live on pub.dev now).

isTaskCancelled actually works now on Android too. Turned out the first pass I mentioned above had a bug of its own: the cancellation registry cleared its own entry the instant it was set, so on Android the whole thing was silently a no-op — unit tests stayed green because a mocked channel can't reproduce that timing race, only caught it once i got a real device to test on. Fixed and device-verified on a Pixel 6 Pro + iOS sim + a 3-device Firebase Test Lab run this time, not just unit tests.

polling shape is still the same as the snippet above. lmk if it's awkward for your use case.