Compose + (State)Flow question. Given the following code (from this template project)

@Composable
fun MyModelScreen(modifier: Modifier = Modifier, viewModel: MyModelViewModel = hiltViewModel()) {
    val lifecycle = LocalLifecycleOwner.current.lifecycle
    val items by produceState<MyModelUiState>(
        initialValue = MyModelUiState.Loading,
        key1 = lifecycle,
        key2 = viewModel
    ) {
        lifecycle.repeatOnLifecycle(state = STARTED) {
            viewModel.uiState.collect { value = it }
        }
    }
    if (items is MyModelUiState.Success) {
        MyModelScreen(
            items = (items as MyModelUiState.Success).data,
            onSave = viewModel::addMyModel,
            modifier = modifier
        )
    }
}

how would one “restart” the collection if/when

uiState

runs into a

catch

which cancels the subscription? In my case

uiState

is (slightly different from the template), something like

flowA.flatMapLatest {...flowB...}.map { Success(it) }.catch { emit(Error(it)) }.stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), Loading)

(though, for the sake of the question, I’m not really sure that detail matters…) I’ve tried things like displaying an error with an “Ok” button, and the button modifies the value of

key1

or

key2

(say, for instance, one of the keys is an

Int

which gets incremented when you press the “Ok” button), but no joy.

This what you’re looking for? https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/retry.html

I have tried adding

retry

before the

catch

and yes, that can work. But, the problem is you (can) either loop forever (don’t limit the number of retries) or eventually end up in the

catch

and you’re back to being out of luck.

I’m not sure I understand what you actually want - if you want to retry an unlimited number of times on failure, then yea if the failure continues to happen you’re going to loop forever. In general, if the flow is throwing an exception other than CancellationException, I would treat that as a bug and propagate it out of the effect right away to either crash the app (production) or fail tests. Otherwise you’re gonna run into all kinds of gross scenarios like this, missing real production bugs, thinking you’ve recovered from a deeper underlying failure state, etc.

@Zach Klippenstein (he/him) [MOD] totally get it. I’m with you. I’d like to find the balance between that and doing something as simple as showing an error to the user and allowing them to hit a button to acknowledge the error and start over.

That sounds better, yea