countly-sdk-android icon indicating copy to clipboard operation
countly-sdk-android copied to clipboard

Event gets associated with wrong user

Open xa17d opened this issue 3 years ago • 6 comments

Events recorded after changeDeviceIdWithoutMerge are still associated with the previous user.

Code to reproduce:

import android.app.Activity
import android.os.Bundle
import ly.count.android.sdk.Countly
import ly.count.android.sdk.CountlyConfig
import ly.count.android.sdk.DeviceId

class DemoActivity : Activity() {

    private lateinit var countly: Countly

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val config = CountlyConfig(
            application,
            CountlyIntegration.COUNTLY_APP_KEY,
            CountlyIntegration.COUNTLY_SERVER_URL
        ).apply {
            setHttpPostForced(true)
            setDeviceId("dg-20210507-test1")
            setLoggingEnabled(true)
            setParameterTamperingProtectionSalt(CountlyIntegration.COUNTLY_SALT)
        }

        countly = Countly.sharedInstance().init(config)

        countly.events().recordEvent("Test", mapOf("event" to "1"))

        countly.changeDeviceIdWithoutMerge(DeviceId.Type.DEVELOPER_SUPPLIED, "dg-20210507-test2")
        countly.events().recordEvent("Test2", mapOf("event" to "2"))

        countly.changeDeviceIdWithoutMerge(DeviceId.Type.DEVELOPER_SUPPLIED, "dg-20210507-test1")
        countly.events().recordEvent("Test", mapOf("event" to "3"))

        countly.doStoredRequests() // send data to server
    }

    override fun onStart() {
        super.onStart()
        countly.onStart(this)
    }

    override fun onStop() {
        super.onStop()
        countly.onStop()
    }
}

The real application is much more complex and initialization is happening in Application.onCreate, but the issue is also reproducible with the code provided above.

Expected Behavior

User with deviceId == "dg-20210507-test1" should have the events:

{"key":"Test", "segmentation":{"event":"1"}}
{"key":"Test", "segmentation":{"event":"3"}}

User with deviceId == "dg-20210507-test2" should have the events:

{"key":"Test2", "segmentation":{"event":"2"}}

Current Behavior

User with deviceId == "dg-20210507-test1" receives all events:

{"key":"Test", "segmentation":{"event":"1"}}
{"key":"Test2", "segmentation":{"event":"2"}}
{"key":"Test", "segmentation":{"event":"3"}}

User with deviceId == "dg-20210507-test2" doesn't receive any events:

Screenshots (if appropriate):

Screenshot of the current behavior from the user profile of user with deviceId == "dg-20210507-test1": Screenshot 2021-05-07 at 19 08 23

Possible Solution

No proposal. I saw that code that should make sure that events are not associated with the wrong deviceId is in place, but it doesn't seem to work in the provided scenario. Could be a race condition when events are tracked too fast after each other.

Steps to Reproduce (for bugs)

  1. Copy code provided at top into an Android project.
  2. Insert proper values for CountlyIntegration.COUNTLY_APP_KEY, CountlyIntegration.COUNTLY_SERVER_URL, CountlyIntegration.COUNTLY_SALT.
  3. Run the app.
  4. Observe events in User Profiles on Countly Server.

More Description

Our app allows to switch users. We noticed that some events are associated with the wrong user. Especially those that are happening close to the changeDeviceIdWithoutMerge call. We tried to eliminate our own code as root cause and then tried to reproduce the issue with a minimal example. The result is the code provided in this issue.

Your Environment

  • Countly Android SDK version: 20.11.8
  • Your Android version: Android 11
  • Your device: Pixel 3a
  • Any changes you have made to this SDK: none. It's the version provided by your maven repository.

xa17d avatar May 07 '21 17:05 xa17d

I have the same issue and its posing a real challenge for us, because it breaks the consistency that we need. Hopefully this is fixed soon, for us it could also be a dealbreaker mid-term.

schusterlich avatar May 18 '21 12:05 schusterlich

Hello. I'm looking into this and we'll try to ship a fix for this in the next release shortly.

ArtursKadikis avatar May 18 '21 12:05 ArtursKadikis