Cache validation does not take into account in-flight requests

[sky-rogersilva]

Hi! I am working on an app that has the following code block:

private val validator = object : Validator<Output> {
    override suspend fun isValid(item: Output): Boolean = isValidUseCase(item)
}

private val store = StoreBuilder
    .from<Input, Output>(
        fetcher = Fetcher.ofResult { input ->
                networkDataSource
                    .getData(
                        attr1 = value1,
			attr2 = value2,
			attr3 = value3,
                    )
                    .toResult()
        },
    )
    .validator(validator)
    .build()

The cache validation does not take into account that when the validator response is false, that there might be an in-flight request that already started the fetcher. And if really there is one, the validator will return false again and will trigger the fetcher one more time, causing two requests.

I would like that when there is already a triggered in-flight request, if another call to the store (with the same input) is made and the validator returns false, then the fetcher shouldn’t be called again and the flow of the existing in-flight request should be returned.

This way, as a workaround, it was implemented the following:

private val mutex = Mutex()

private val validator = object : Validator<Output> {
    override suspend fun isValid(item: Output): Boolean =
        mutex.withLock { isValidUseCase(item) }
}

private val store = StoreBuilder
    .from<Input, Output>(
        fetcher = Fetcher.ofResult { input ->
            mutex.withLock {
                networkDataSource
                    .getData(
                        attr1 = value1,
			attr2 = value2,
			attr3 = value3,
                    )
                    .toResult()
            }
        },
    )
    .validator(validator)
    .build()

That is, it was used a Mutex to handle the fetcher as a mutual exclusion region. This way, when there is an in-flight request that started the fetcher and another call tries to start the fetcher again, then this last one stays on hold through the validator until the first in-flight request is finished.

Question: wasn't it foreseen initially this multithreaded use case for validators in Store5 and this can be an improvement in the future for the library, or is this an expected behaviour for validators? Additionally, could I handle the mentioned problem without use Mutex trying to use another feature from Store5?