How to use keepUpstreamAlive option from the public API?

[ferinagy]

In our app (Android), we have a custom coroutine scope that is active, while the user is logged in and canceled once they log out. It would be nice to be able to scope the fetcher calls to this scope, so the running call kept even if there are no subscribers, but only cancel on logout. Imagine starting the call on one screen, then moving away to a screen that does not subscribe to the store and returning back - it would be great to just receive result of the first call instead of restarting the call again.

I found out that ChannelManager and Multicaster does have an arg keepUpstreamAlive which based on the doc should be doing what I want, but I found no way to set the option from the public api of Store or Store.Builder. What I see is that FetcherController always sets the buffer to 0 and uses the default of keepUpstreamAlive = false.

Furthermore, also when building from source and setting keepUpstreamAlive = true and bufferSize = 1, I still see the fetcher cancelling the request when all subscribers unsubscribe.

Did I miss something and is there a way to achieve the above? If there is not, shouldn't there be?

Thanks

PS. I am experimenting with GitHub discussions because I am not sure this warrants opening an issue, but I can open one if you think it would better fit there.

[yigit]

The keep alive is for sharing purposes when there is no source of truth so it won't help here.

Also, from Store's perspective, keeping those calls alive looks very wrong (keep in mind, they could also be streams and you wouldn't want Store to keep every stream alive).

I think it is better for you to solve this outside Store. For such calls where you want it to stay alive, you can move the store request to the userScope and pass it back to the caller scope using an explicit channel. A bit verbose but given that it is intentionally denying structured concurrency, it might even be the right thing to keep verbose. (you can also always consider writing a wrapper for it :) )

[ferinagy]

Thanks for the explanation and tips. Few of my closing thoughts:

The keep alive is for sharing purposes when there is no source of truth...

I had no source of truth when I tested, just plain Fetcher 🤷

from Store's perspective, keeping those calls alive looks very wrong

I definitely agree it should not be the default behavior out of the box. But if you know your domain, it could IMHO be a reasonable option. Eg. when using store for a call with a single key - like a list of articles - it would imo be ok.

it is intentionally denying structured concurrency

Isn't store already doing that anyway, just with ref counting?

you can also always consider writing a wrapper for it

I will give it a go, but with other customizations like subsequent loading states from #124, I am not sure there will be much left to wrap 😄

[yigit]

I had no source of truth when I tested, just plain Fetcher

That is fine as Store will keep the fetcher active as long as there is a collector. If there are collectors, we'll cancel it (assuming it handles cancellation since cancelaltion is cooperative)

it is intentionally denying structured concurrency

Isn't store already doing that anyway, just with ref counting?

Not really, we are sharing resources between collectors but we still cancel them where they are not needed. That is not much different than how sharing works except we have some custom logic here (also, sharing in Flow didn't exist when we wrote that part :) )

you can also always consider writing a wrapper for it

I will give it a go, but with other customizations like subsequent loading states from #124, I am not sure there will be much left to wrap

If you have requests that you don't want cancelled, why not just launch a collector in your userScope in parallel?