Store icon indicating copy to clipboard operation
Store copied to clipboard

[BUG] MutableStore.write reports success when SourceOfTruth writer throws

Open ahmounir opened this issue 1 month ago • 0 comments

Thanks for the awesome library, but I just ran into something odd while poking at mutable writes.

Describe the bug

When the SourceOfTruth writer throws, MutableStore.write() still returns StoreWriteResponse.Success, so callers get an explicit success even though nothing was persisted. Maybe it's intentional to swallow Exceptions -?- , but I think that I shouldn't receive an excplicit success when my data was not written to store. , Also I've spent hours trying to catch this IllegalStateException thrown error but I couldn't

To Reproduce

Steps to see it fail:

  1. Check out the current main of Store5.
  2. Add this regression to store/src/commonTest/kotlin/org/mobilenativefoundation/store/store5/mutablestore/RealMutableStoreTest.kt (around lines 301‑325):
@Test
fun write_givenSourceOfTruthFailure_whenCalled_thenSurfacesWriteError() = runTest {
    val failingKey = "sotFailKey"
    testSourceOfTruth.throwOnWrite(failingKey) {
        IllegalStateException("Catch me if you can")
    }
    val request = StoreWriteRequest.of<String, Note, Unit>(
        key = failingKey,
        value = Note("idFail", "contentFail"),
        created = 3333L,
        onCompletions = null,
    )

    val response = mutableStore.write(request)

    val errorResponse = assertIs<StoreWriteResponse.Error.Exception>(response)
    val writeException = assertIs<SourceOfTruth.WriteException>(errorResponse.error)
    val cause = assertIs<IllegalStateException>(writeException.cause)
    assertEquals("Catch me if you can", cause.message)
}
  1. Run ./gradlew :store:jvmTest. or just run this added test directly from Android studio
  2. Watch the new test fail because the result is StoreWriteResponse.Success.

Expected behavior

If the SourceOfTruth writer throws, MutableStore.write() (and the write stream) should return StoreWriteResponse.Error.Exception with the underlying SourceOfTruth.WriteException, so callers know the data never made it to the cache.

Screenshots

N/A

Smartphone (please complete the following information):

  • Device: NA (host JVM tests)
  • OS: macOS
  • Store Version: 5.1.0‑alpha07 (current main)

Additional context

You can also reproduce in a real app by wiring a failing SourceOfTruth writer—the write API happily reports success even though readers later emit a write error. I’d expect symmetry between the two so we can retry or surface the failure immediately. I tried reading the same key before and after throwing , but I couldn't catch the exception

Thanks in advance

ahmounir avatar Nov 15 '25 12:11 ahmounir