Android: java.lang.RuntimeException Could not invoke HeadlessJsTaskSupport.notifyTaskFinished

[brunezkey]

Required Reading

• Confirmed

Plugin Version

4.18.3

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

Google Pixel 6, Samsung, Moto G Power

Device operating-systems(s)

Android 12, 13, 14, 15

React Native / Expo version

0.72.17

What happened?

After upgrading our package from 4.17.6 to 4.18.3, we started seeing the following error in our error tracking tools:

java.lang.RuntimeException: Could not invoke HeadlessJsTaskSupport.notifyTaskFinished

java.lang.AssertionError: Tried to finish non-existent task with id 133.

  assertCondition(Assertions.java:88)
  
  finishTask(HeadlessJsTaskContext.java:179)
  
  notifyTaskFinished(HeadlessJsTaskSupportModule.java:53)

Our headless task registration (just for completeness):

BackgroundGeolocation.registerHeadlessTask(
  throttle(async (event: HeadlessTaskEvent) => {
    if (event.name === BackgroundGeolocation.EVENT_LOCATION) {
      // Persist location to DB and save the last position
    }
  }, FIFTEEN_SECONDS),
)

It looks like a significant refactor was made to headless task management between 4.18.0 and 4.18.1, but we're unsure what specifically is causing the crash on affected devices.

We haven't been able to reproduce this issue locally, but we've observed around 100 occurrences in production over the past 15 days. Any insights or guidance on potential causes would be greatly appreciated.

Plugin Code and/or Config

const geolocationSettings: Config = {
  desiredAccuracy:
    Platform.OS === 'ios'
      ? BackgroundGeolocation.DESIRED_ACCURACY_NAVIGATION
      : BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
  distanceFilter: DISTANCE_METERS,
  disableElasticity: true,
  enableHeadless: true,
  fastestLocationUpdateInterval: INTERVAL_MILLISECONDS,
  foregroundService: true,
  notification: {
    title: 'App',
    text: 'Tracking your location',
    smallIcon: 'ic_notification',
  },
  allowIdenticalLocations: true,
  disableStopDetection: false,
  stopOnTerminate: false,
  startOnBoot: true,
  maxRecordsToPersist: 1,
  disableMotionActivityUpdates: Platform.OS !== 'ios',
  reset: true,
  locationAuthorizationRequest: 'Always',
  stopTimeout: STOP_TIMEOUT,
  batchSync: false,
  autoSync: true,
  url: '',
  httpRootProperty: '',
  locationTemplate: '',
  headers: {},
}

Relevant log output

java.lang.RuntimeException: Could not invoke HeadlessJsTaskSupport.notifyTaskFinished

  handleUncaughtException(MainApplication.java:87)
  
  uncaughtException(MainApplication.java:75)
  
  uncaughtException(BackgroundGeolocation.java:98)
  
  uncaughtException(ar.java:9)
  
  uncaughtException(ThreadGroup.java:1071)
  
  uncaughtException(ThreadGroup.java:1066)
  
  dispatchUncaughtException(Thread.java:2306)

java.lang.reflect.InvocationTargetException: null

  invoke(Method.java:-2)
  
  invoke(JavaMethodWrapper.java:372)
  
  invoke(JavaModuleWrapper.java:188)
  
  run(NativeRunnable.java:-2)
  
  handleCallback(Handler.java:958)
  
  dispatchMessage(Handler.java:99)
  
  dispatchMessage(MessageQueueThreadHandler.java:27)
  
  loopOnce(Looper.java:230)
  
  loop(Looper.java:319)
  
  run(MessageQueueThreadImpl.java:228)
  
  run(Thread.java:1012)

java.lang.AssertionError: Tried to finish non-existent task with id 133.

  assertCondition(Assertions.java:88)
  
  finishTask(HeadlessJsTaskContext.java:179)
  
  notifyTaskFinished(HeadlessJsTaskSupportModule.java:53)
  
  invoke(Method.java:-2)
  
  invoke(JavaMethodWrapper.java:372)
  
  invoke(JavaModuleWrapper.java:188)
  
  run(NativeRunnable.java:-2)
  
  handleCallback(Handler.java:958)
  
  dispatchMessage(Handler.java:99)
  
  dispatchMessage(MessageQueueThreadHandler.java:27)
  
  loopOnce(Looper.java:230)
  
  loop(Looper.java:319)
  
  run(MessageQueueThreadImpl.java:228)
  
  run(Thread.java:1012)

[christocracy]

I can't see how an exception could possibly not be caught by my code

I don't even see a reference to my code HeadlessTaskManager.java in your stacktrace.

[christocracy]

I've never seen anyone throttle a headless-task before. I wouldn't do that.

0.72.17

You might try migrating to latest RN.

[abhayagrawal-fareye]

We are facing the same issue in Production. The frequency of this issue is very concerning

[christocracy]

This plug-ins namespace is not referenced in the stacktrace.

[abhayagrawal-fareye]

This plug-ins namespace is not referenced in the stacktrace. @christocracy

I have this in my stacktrace -

         Fatal Exception: java.lang.RuntimeException: Could not invoke HeadlessJsTaskSupport.notifyTaskFinished
       at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:381)
       at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:149)
       at com.facebook.jni.NativeRunnable.run(NativeRunnable.java)
       at android.os.Handler.handleCallback(Handler.java:958)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
       at android.os.Looper.loopOnce(Looper.java:257)
       at android.os.Looper.loop(Looper.java:368)
       at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:234)
       at java.lang.Thread.run(Thread.java:1012)
        ```

    Caused by java.lang.reflect.InvocationTargetException:
   at java.lang.reflect.Method.invoke(Method.java)
   at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
   at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:149)
   at com.facebook.jni.NativeRunnable.run(NativeRunnable.java)
   at android.os.Handler.handleCallback(Handler.java:958)
   at android.os.Handler.dispatchMessage(Handler.java:99)
   at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
   at android.os.Looper.loopOnce(Looper.java:257)
   at android.os.Looper.loop(Looper.java:368)
   at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:234)
   at java.lang.Thread.run(Thread.java:1012)

```          Caused by java.lang.AssertionError: Tried to finish non-existent task with id 335.
       at com.facebook.infer.annotation.Assertions.assertCondition(Assertions.java:88)
       at com.facebook.react.jstasks.HeadlessJsTaskContext.finishTask(HeadlessJsTaskContext.java:179)
       at com.facebook.react.modules.core.HeadlessJsTaskSupportModule.notifyTaskFinished(HeadlessJsTaskSupportModule.java:53)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
       at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:149)
       at com.facebook.jni.NativeRunnable.run(NativeRunnable.java)
       at android.os.Handler.handleCallback(Handler.java:958)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
       at android.os.Looper.loopOnce(Looper.java:257)
       at android.os.Looper.loop(Looper.java:368)
       at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:234)
       at java.lang.Thread.run(Thread.java:1012)```

[christocracy]

See here to learn how to properly syntax highlight multiline blocks (ie: "fenced code blocks")

[tsachit]

This is happening to us as well. We're using react native 0.74 and using the headless feature as well. Any fix on this?

[christocracy]

Let me know how to reproduce. The stacktrace shows no reference to this plug-in.

[tsachit]

Let me know how to reproduce. The stacktrace shows no reference to this plug-in.

We only have this at the moment for headless. Let me now if you want to look at config for BackgroundGeolocation.ready

const HeadlessTask = async event => {
  try {
    if (!userLoggedIn) return;
    switch (event.name) {
      case 'location': {
        const { latitude, longitude, accuracy } = event.params.coords;
        await trackLocation({ latitude, longitude, accuracy });
        break;
      }
      default:
        break;
    }
  } catch (e) {
    logException(e, { type: 'Background Geo - HeadlessTask' });
  }
};

BackgroundGeolocation.registerHeadlessTask(HeadlessTask);

[mikehardy]

Hey evereyone 👋 there is a lesson here. What is the lesson? Logging issues against old versions of software is an unproductive use of time when contrasted with updating your versions then attempting to reproduce then spending time tracking the issue.

facebook/react-native@b4532ad

react-native 0.77 is out and contains the fix for this

it's upstream, not related to this repository

[mikehardy]

(note that I found this by just doing this search, and following the trail to the commit then to see the release tag on the commit - it took me about a minute --> https://github.com/facebook/react-native/issues?q=Tried%20to%20finish%20non-existent%20task%20with%20id%20 -- well worth the effort)

[brunezkey]

Thanks for the heads-up, @mikehardy! I appreciate you taking that minute to check this out - and, of course... for the free lesson!

Unfortunately, we're gradually bumping our React Native version since we're maintaining an enterprise product, and we need to plan carefully to avoid breaking other packages during the upgrade.

We've downgraded this package to a lower version (4.17.6, which was the last stable version for us), and so far, we haven’t seen the issue reappear in production.

I wish I could provide exact steps to reproduce the issue, but we haven’t been able to replicate it locally yet. However, we're almost certain it’s related to this package. I’ll confirm in a couple of days if we continue to see this trend.

For now, it looks like we’ll be stuck on an older version until we can upgrade React Native to the latest version.

Thanks for the amazing work you guys do maintaining this library, it's very good and works like a charm. Not so much for the passive-aggressive responses though.

Cheers!

[mikehardy]

You may be able to build rn from source to get that patch in there, I've had success that way before. Arduous but doable. As to the responses you're not wrong, but it is kind of shocking the lack of effort people put in when asking for help. Occasionally my frustration seeps out. Fir the record Cris is the one and only maintainer here, I just drop occasionally annoying comments now and again when I see things related or that might affect my projects as well. Cheers

[brunezkey]

@mikehardy I totally get your point. I was hesitant to create an issue with no reproduction steps and knew it would generate some sort of backlash.

My sole intention is to help generate visibility to an actual issue our users are facing in production, which seems to be directly (or indirectly?) related to this package update. Perhaps someone else already faced it and found a potential solution for it.

Will try my best to provide you some reproduction steps once we figure out what's causing Android to crash, but it's a tricky one.

[christocracy]

but it is kind of shocking the lack of effort people put in when asking for help.

It’s true. Mike and I have both been maintaining some rather complex and particularly long-lived projects for many years (over 10 years for background-geolocation).

So yea, it’s not going to be always roses with user-responses, particularly so when there’s a stacktrace without reference to this SDK’s namespace while the user is sitting back upon a relatively old version of RN.

I’m supporting this plug-in for Cordova, Capacitor and Flutter as well (in addition to the supporting background-fetch), waking up each day to a page full of support requests. The issues with solid evidence get the focus.

[codephoenix-design]

We are also seeing this issue, though I don't believe it is tied to React Native Background Geolocation as we are currently on version 4.16.3.

We also will be staying on RN 0.74.5 until react-native-maps supports the new architecture.

Our attempt to solve this is by using patch-package in combination with the commit @mikehardy found.

1. Install patch-package and follow their setup instructions
2. Copy over the modifications from facebook/react-native@b4532ad
3. npx patch-package react-native
4. Verify the patch file generated makes the same changes.

Since there is no clear recreation steps, we will have to cross our fingers and wait to see the crash log reports once this goes live.

Hope this helps anyone else who stumbles across this issue.

[brunezkey]

@codephoenix-design Just as an FYI, we downgraded to 4.17.6, and we haven't seen any occurrence of this issue in the last two weeks - around 4k users. No longer crossing fingers here.

We have yet to upgrade or patch React Native. But we haven't seen any crash reports on Android ever since we downgraded, in case it helps anyone.