incomprehensible flow collection

While writing a test for my implementation with FlowSharedPreferences i discovered a unexpected behavior of the Flow:

Test Code:

    @Test
    fun testBug3() = runTest {

        val tokenPreferences = getApplicationContext<MDEApplication>().getSharedPreferences("Token", Context.MODE_PRIVATE)
        val tokenPreferencesFlow = FlowSharedPreferences(tokenPreferences).apply { clear() }
        val accessTokenPreferenceFlow = tokenPreferencesFlow.getFloat("access_token", defaultValue = 0.5f)

        launch {
            Log.i("TESTX", "collection started!")
            accessTokenPreferenceFlow.asFlow()
//                .distinctUntilChanged()
                .collectLatest {
                    Log.i("TESTX", "collected: $it")
                }
        }

        launch {
            Log.i("TESTX", "setAndCommit 20")
            accessTokenPreferenceFlow.setAndCommit(20f)
            Log.i("TESTX", "setAndCommit 30")
            accessTokenPreferenceFlow.setAndCommit(30f)
            Log.i("TESTX", "setAndCommit 50")
            accessTokenPreferenceFlow.setAndCommit(50f)
        }
    }
}

Output is:

TEST: collection started!
TEST: setAndCommit 20
TEST: collected: 20.0
TEST: setAndCommit 30
TEST: setAndCommit 50
TEST: collected: 50.0
TEST: collected: 50.0

For me i see two problems:

1. 30 is not collected
2. 50 is collected twice

As far as i can see right know, the two issues belong together.

Why i need this fixed in any way

In my Test i need to have a start value collected on flow collection start (Value X). Then later on, a second value (Y) is set and needs to be processed by the collection also. But right now, the first value is never processed, instead the first collection is the second value (Y). The first value is skipped for some unknown reason like 30 in the example above.

Sometimes even worse:

setAndCommit X
collection started!
setAndCommit Y
collected: X

Y is never collected. Right know i really don’t know whats going on. 😃

[TZanke]

After some hours trying to write a test, i can conclude the following:

1) This will not work, cause get() called inside OnSharedPreferenceChangeListener also does return a newer value then the event is originated from. The listener is just a little bit slow.

2) This should not make any difference at all.

3 & 4) As you said Also distinctUntilChanged() could break any logic waiting for the same value. So very client related option.

[tfcporciuncula]

Thanks for the re-investigation!

So the listener event started by 30 will change to a 50 inside the flow. Then the flow continues to the collection and prints 50. Afterwards the delayed listener event of 50 triggers the flow again, getting the 50 and also collects a 50.

Yeah, this kind of behavior is still reasonable to me given what we’re doing there.

But, is this a bug?

I say nay! 😃

About 3, I would prefer to not add distinctUntilChanged() in the lib and leave that as an option for clients. About 1 and 2, I’m not super confident about these changes and I would prefer to only go for something different than what we have if we’re really able to confidently narrow the issue down to something we fully understand and can reproduce. I apologize for not being of much help here, but if at any point you feel some of these changes should really make their way into the library, feel free to open an MR with a test as well!

I’ll leave the issue open for now and close it eventually if there’s no more activity ✌️