fix crash in presence degradation reporter

[rajramsaroop]

Today if you try to use Presence Degradation Reporter with a Ditto SDK >= 4.8.0 the app will crash with the following stack trace:

Process: live.ditto.dittoupdatetest, PID: 24145
java.lang.NoSuchMethodError: No static method upsert$default(Llive/ditto/DittoScopedWriteTransaction;Ljava/lang/Object;Llive/ditto/DittoWriteStrategy;ILjava/lang/Object;)Llive/ditto/DittoDocumentId; in class Llive/ditto/DittoScopedWriteTransaction; or its super classes (declaration of 'live.ditto.DittoScopedWriteTransaction' appears in /data/app/~~_AShLrljJsZ9i23CNU4Lpg==/live.ditto.dittoupdatetest-hI_e-kQ92pOsuTCw8rdjuQ==/base.apk!classes6.dex)
    at live.ditto.presencedegradationreporter.repositories.PeersRepository$upsertPeers$2$1.invoke(PeersRepository.kt:43)
    at live.ditto.presencedegradationreporter.repositories.PeersRepository$upsertPeers$2$1.invoke(PeersRepository.kt:41)
    at live.ditto.DittoStore$write$1$1.invoke(DittoStore.kt:354)
    at live.ditto.DittoStore$write$1$1.invoke(DittoStore.kt:347)
    at live.ditto.TransactionsKt.commitAndReturn(transactions.kt:37)
    at live.ditto.TransactionsKt.commitAndReturn$default(transactions.kt:31)
    at live.ditto.DittoStore$write$1.invoke(DittoStore.kt:347)
    at live.ditto.DittoStore$write$1.invoke(DittoStore.kt:346)
    at live.ditto.internal.ffi.DittoHandle$withUnwrapped$1.invoke(DittoHandle.kt:33)
    at live.ditto.internal.ffi.DittoHandle$withUnwrapped$1.invoke(DittoHandle.kt:31)
    at live.ditto.internal.ffi.DittoHandleWrapper.with(DittoHandleWrapper.kt:43)
    at live.ditto.internal.ffi.DittoHandle$DefaultImpls.withUnwrapped(DittoHandle.kt:31)
    at live.ditto.internal.ffi.DittoHandleWrapper.withUnwrapped(DittoHandleWrapper.kt:9)
    at live.ditto.DittoStore.write(DittoStore.kt:346)
    at live.ditto.presencedegradationreporter.repositories.PeersRepository$upsertPeers$2.invokeSuspend(PeersRepository.kt:41)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
    at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
    at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
    Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@1ff0f6c, Dispatchers.Main.immediate]

This is a runtime exception and occurs because the JVM couldn't find a method that matches the above method signature. A method that matches this does not match the generated java bytecode so it crashes with this exception.

The workaround for now is to explicitly add argument labels to functions so that it calls the right method. I am still investigating what work may need to be done on the SDK side to fix this.

I have isolated it to Ditto SDK 4.8.0 and above because of changes in this PR: https://github.com/getditto/ditto/pull/13336

[phatblat]

Yikes! So, adding the optional hint parameter to DittoScopedWriteTransaction.upsert caused bytecode incompatibility.

Can this be resolved with a gradle clean?

[rajramsaroop]

clean didn't seem to fix it.

I imagine the same would be true for DittoCollection.upsert() as well, but I haven't tested that. And now my Android Studio is being weird and not showing me the decompiled class right now :(

[bplattenburg]

@rajramsaroop @phatblat did we log something upsteam on the SDK end to dig deeper? If so, can we link it here?

[phatblat]

@rajramsaroop @phatblat did we log something upsteam on the SDK end to dig deeper? If so, can we link it here?

No, this was the first I learned of this issue. Since this is something we've already released we can't change it now. If we revert the APIs to what they were before 4.8.0 we'd have the same type of bytecode incompatibility with the new version.