I used the replaying behavior in rx to cache the latest emit of database, and scope in rx is .. I guess the duration of FooRepository instance lifetime (foo flow instance lifetime)? Well..semantically its not GlobalScope since FooRepository say only lives during user being logged in -- dagger specifies this If I were to have scope as param that would not be nice api. Or maybe use GlobalScope and just leave it up to dagger to scope the FooRepository object, and therefore GC eats this when it goes out of "scope"? Would that be a leak?

If I were to have scope as param that would not be nice api.

No, it’s very nice API, it force you to think on lifecycle of this thing, with RxJava you just do not care and may easily leak

No in rx it doesnt leak, it lives as long as the val owner, i.e. repo lives why would you want to pass different scope, I just want to get db state, and its nice to get memcached one right away

It cannot be stateless by definition! If you have hot stream (support multiple receivers or caching) it already stateful, but with rx you just doesn't see it without scope

Okay I see your point, caching is state, still wouldnt leak the way I use my "object" scopes and refcount but okay I'm trying it in flow with the global scope but it doesnt work 😕

object FooRepository {

    val foos: Flow<List<Foo>> = flow { emit(readFoos()) }.shareIn(scope = GlobalScope, started = SharingStarted.Lazily())
}

Activity1 {
	scope.launch {
        FooRepository.foos
            .collect {
                Log.d("Default", "activity1=$it")
            }
	}
}

Activity2 {
	scope.launch {
        FooRepository.foos
            .collect {
                Log.d("Default", "activity2=$it")
            }
	}
}

Activity 1 initiates readFoo and gets result, then via a button I move to Activity2 and that doesnt receive the cached result, nor initiates readFoos -- I must be doing something wrong (If I remove the shareIn and place it in a getter then it works as expected, but obviously without the caching, so the callsites I think are okay) i.e. using the shareIn wrongly

It's actual leak or not purely depend on Flow/Observable implementation which you making hot

Its not a leak if you handle the disposable autoConnect gives you or make sure you unsubscribe all when using refCount but sure, I see your point

Right, if you manage it manually

which is the same as making sure you dont forget to call scope.cancel basically

Consumer can just pass scope in such cases

I'd prefer not to but its true my Repo functions are cold/suspending so caller choses its own scope, so why not the database stream aswell to make it symmetrical, but okay I'll think about it, but lets not diverge from my code not working 😄