Custom actions on Android from stream events are not being reported unless we manually start a view with a different name than the last view
almovsesanso opened this issue · 3 comments
This problem is impacting Android only, not iOS.
We're using the Plaid SDK which has 3 distinct streams that we listen to get user actions which we're funneling to DD as custom user actions.
What we're observing is that when we call:
DatadogSdk.instance.rum?.addUserAction(RumUserActionType.custom, "PLAID_ACTION"); from within those stream listener callbacks, we're not getting back anything on the DD portal. We do see the Load screen xyz indicating a view was started and we do see a tap action when the user clicks a button on said screen but nothing else from all the user interactions that we're getting asynchronously through the stream listeners.
This is happening only on Android. On iOS we're getting those custom actions just fine.
What ended up working for us at the end is calling:
DatadogSdk.instance.rum?.startView("fake_view_name");
in the initState method of the screen.
And then we started seeing all the custom actions on the DD portal immediately.
Notice that if the fake_view_name was the same as the actual view name, we don't see those custom actions anymore.
We're using the DatadogNavigationObserver to handle our views and never encountered any similar issue before. We always see the relevant Load screen events on all of our navigation events and haven't experienced any loss of events except for here for custom actions on Android.
Few of the other things we tried was using:
Future.delayed( Duration(milliseconds: 1), () => DatadogSdk.instance.rum?.addUserAction( RumUserActionType.custom, "PLAID_ACTION"));
The delay duration itself did not seem very relevant, just 1 millisecond seemed like it was enough to also fix the problem without having to start a view manually. However, for some reason that worked on the onExit and onSuccess but not for the onEvent callbacks. Making the delay a random number of seconds for each callback and adding locks did not seem to matter either as we were still seeing loss of custom actions. In the end, only starting a view with a different name seemed to be the only solution that unblocked all the custom actions.
Hi @almovsesanso,
This does sound very weird, I'll try to find some time to look into it. Would you be able to provide a simple sample that reproduces the issue?
Hi @almovsesanso ,
Were you able to find what might have been causing this, find a workaround, or produce a sample that reproduces the issue?
Hi @almovsesanso ,
Were you able to find what might have been causing this, find a workaround, or produce a sample that reproduces the issue?
Unfortunately not. We changed our navigation logic since but the problem is still occurring. I am not sure how to provide a minimal repro. I'll close this issue for now and potentially re-open it if/when I have a minimal repro.