Android Fatal Exception ObjectAlreadyConsumedException

[mikehardy]

          Hi @mikehardy 

After the fix in #1168 i have started seeing many errors in Crashlytics with the following stack trace:

Fatal Exception: com.facebook.react.bridge.ObjectAlreadyConsumedException
Map already consumed

com.facebook.react.bridge.WritableNativeMap.mergeNativeMap (WritableNativeMap.kt)
com.facebook.react.bridge.WritableNativeMap.merge (WritableNativeMap.kt:47)
com.facebook.react.bridge.WritableNativeMap.copy (WritableNativeMap.kt:52)
com.facebook.react.jstasks.HeadlessJsTaskConfig.<init> (HeadlessJsTaskConfig.java:90)
com.facebook.react.jstasks.HeadlessJsTaskContext.startTask (HeadlessJsTaskContext.java:113)
com.facebook.react.jstasks.HeadlessJsTaskContext.startTask (HeadlessJsTaskContext.java:91)
io.invertase.notifee.HeadlessTask.invokeStartTask (HeadlessTask.java:235)
io.invertase.notifee.HeadlessTask.lambda$drainTaskQueue$0 (HeadlessTask.java:347)
io.invertase.notifee.HeadlessTask.$r8$lambda$TfM4uS4TmugyY-kRBF4YHDzDJ04
io.invertase.notifee.HeadlessTask$$ExternalSyntheticLambda0.run (D8$$SyntheticClass)

Unfortunately i cant reproduce this issue locally,
After looking at the stack trace i saw that there is a WritableMap in the TaskConfig class
and i think that instead of

      // Insert our custom taskId for users to call finishHeadlessTask(taskId) with.
      params.putInt("taskId", mTaskId);
      mParams = params;

we need:

     // Create a copy of the original params map to ensure it is not modified
      mParams = params.copy();  // Using copy() to create a new independent map

      // Insert our custom taskId for users to call finishHeadlessTask(taskId) with.
      mParams.putInt("taskId", mTaskId);

What do you think ?
If it is acceptable, i can open a PR.

Thanks

Originally posted by @MaxToyberman in #266 (comment)

[mikehardy]

Related: transistorsoft/react-native-background-geolocation#2235 (comment)

[mikehardy]

@MaxToyberman - PR #1176 should fix this, and it's already released as v9.1.8 here as of last night, could you try that?

Meanwhile I'm going to locally revert that and see if I can reproduce it to affirm I see the crash (rather than just "the possibility of a crash via code inspection") and that this does actually fix it. But I may never be able to reproduce so getting it in a release with someone that has observed crashes in the wild could really help.

Hypothesis is that this is what can happen if multiple events are triggered in the background on a killed app all at once, queueing rapidly enough that there are multiple events in the queue when react-native startup is complete and we internally race to drain the queue, with multiple queued event queue drains instead of just one.

[mikehardy]

@MaxToyberman I'm unable to reproduce it despite some effort but I really do think the fix in v9.1.8 should fix it based on code inspection, I'll have to wait to hear back from you after rolling that out.

[MaxToyberman]

Thanks @mikehardy

Sure, we are going to deploy the fix on Monday,
I will monitor it and let you know.