debug flag ignored - errors logged

[adamcclifton]

When debug is disabled in the config, debug errors and warnings are still firing.

Primarily the "Failed to send # events." error.

I understand that this is not a problem for analytics, as these events are stored and sent later. But these errors are spamming our stability monitoring in production and cannot be disabled.

It seems like this problem was fixed in version 2.10.0 according to this issue:
#704
And if I roll back to version 2.10.0 things work as expected, the errors only appear if debug: true.

So maybe there has been a regression in later releases?

• analytics-react-native version: 2.16.0 (and 2.15.0 at least)
• Integrations versions (if used):
• React Native version: 0.71.10
• iOS or Android or both? iOS confirmed

Steps to reproduce

• Create and run app, with debug: true and wifi enabled.
• Close the app, hopefully this will leave some unsent events.
• Turn off wifi and relaunch app.
• Note that the "Failed to send # events." error is triggered. Hopefully it will just work at startup with events from the previous session, otherwise you may have to trigger some events and wait.
• Now set debug: false and relaunch the app.
• Note that the "Failed to send # events." error is still appearing, even tho debug is disabled.

Expected behavior
The "Failed to send # events." error does not appear when debug is set to false

Actual behavior
The "Failed to send # events." error is appearing when debug is set to false

[ammarlakho]

Facing the same problem of debug flag being ignored but not just for errors, it's happening for all logs.

I obviously need to disallow logs for my app in production but the logs for each event are being logged.

analytics-react-native version: 2.1.10
Integrations versions (if used):
React Native version: 0.71.12
iOS or Android or both? Android confirmed.

As you can see from the screenshot, segment.logger is disabled but i am still getting logs for each event.

[oscb]

@ammarlakho @adamcclifton this is very weird. Thanks for the detailed report!
I just quick tested in the example app in the monorepo but cannot get this to reproduce yet. Will keep testing.

The code that actually enables/disables through the config.debug is here, though I see it also uses the env by default. Overall is a little convoluted imo, will remove the weird logic here.

Are you seeing this in device or in the simulator? Could you share your client config settings? Where do you instantiate your client?

[ammarlakho]

@oscb i figured out the reason why the logs were not stopping even when logger was disabled. We're using a DestinationPlugin (Moengage) and removing that makes the logs disappear too... No idea why that happens though lol

[oscb]

@ammarlakho I'm very curious. Is this destination plugin for Moengage a custom one?

[ammarlakho]

@oscb
Thanks for the help but we finally figured it out completely. We were using a plugin from this library: https://www.npmjs.com/package/react-native-moengage at an older version. And it was directly just console.logging....

The latest version for that library has fixed the issue (by letting us set a log level) though so we'll be upgrading soon

[adamcclifton]

@ammarlakho @adamcclifton this is very weird. Thanks for the detailed report! I just quick tested in the example app in the monorepo but cannot get this to reproduce yet. Will keep testing.

The code that actually enables/disables through the config.debug is here, though I see it also uses the env by default. Overall is a little convoluted imo, will remove the weird logic here.

Are you seeing this in device or in the simulator? Could you share your client config settings? Where do you instantiate your client?

Hi thanks for checking that out. I cant seem to reproduce in the same way now, with the visible error, but i can see where the problem is now.
We were not handling disable on the logger we supplied to createClient.

This does lead to more confusion tho, as on production that means all logs would be disabled, and we would want to report errors to bugsnag. But then again, "failed to send x events" is also an error, and we don't want that to go to bugsnag (the original issue).

It feels like that should be more of a warning than an error, but that's probably up for debate.
Our solution will be to ignore the disabled callback, send all errors to bugsnag, and filter out "failed to send" there.