Transitions fail to return to original state after animateToStart() and beginDelayedTransition() [300157785]

Fixed

Bug

Status Update

No update yet.

Description

jb...@google.com

created issue #1

Sep 13, 2023 12:31AM

Component used: Transition Version used: 1.5.0-alpha02 Devices/Android versions reproduced on: API 34

If you do a gesture back in Fragments using transitions and cancel the gesture multiple times, after the first cancel, starting the gesture will result in the transition on the exiting view failing to run.

I believe the cause of this is that the beginDelayedTransition() called by with a 0 duration called by Fragment never triggers this onAnimatedEnd() callback in Visibility. That results in the visibility failing to be added removed from the overlay and so the subsequent transitions on the view do not run.

Here are logs synced with the calls from Fragment and Visibility. I would expect there to be an onAnimationEnd reversed=false log before the onTransitionEnd in Visibility.

 V  Animating to start (in Fragment)
 D  onAnimationEnd reversed=true (in Visibility)
 V  Calling beginDelayedTransition (in Fragment)
 D  onTransitionEnd (in Visibility)
 V  On transitionEnd of beginDelayedTransition (in Fragment)

The can be reproduced by patching in aosp/2748867 and doing the following in the navigation-integration app:

Launch App
Press the "Navigate Next" button 2 times to get to the "two" screen
Start a gesture back to the "one" screen and cancel it
Start another gesture back to the "one" screen and the "two" screen will immediately go blank

Comments

mo...@google.com <mo...@google.com> Sep 13, 2023 04:31PM

Accepted by mo...@google.com.

mo...@google.com <mo...@google.com> #2Sep 18, 2023 08:29PM

Assigned to jb...@google.com.

Is there any updates? This is a big problem!

va...@google.com <va...@google.com> #3Sep 21, 2023 06:57PM

Hi there - could you provide more context on the issue & a sample project to reproduce? Database locked exceptions are quite difficult to pinpoint without a repro project. Thanks!

va...@google.com <va...@google.com> #4Sep 21, 2023 07:08PM

Hi. It is reproduceable on some users by using this code:

suspend fun <R> MyDatabase.workaroundWithTransaction(block: suspend TransactionScope<R>.() -> R) {
    useWriterConnection {
        it.immediateTransaction(block)
    }

    // TODO: Temporally fix https://issuetracker.google.com/issues/340606803#comment2
    // Manually triggers invalidation
    invalidationTracker.refreshAsync()
}

jb...@google.com <jb...@google.com> #5Sep 26, 2023 08:12PM

Maybe it is about this? https://android-review.googlesource.com/c/platform/frameworks/support/+/3114928

I am not sure.

jb...@google.com <jb...@google.com> #6Sep 26, 2023 08:46PM

Hi. Please merge the pull request. This is big problem!

ap...@google.com <ap...@google.com> #7Sep 26, 2023 08:56PM

Hi. Is there any updates on this problem?

jb...@google.com <jb...@google.com> #8Oct 25, 2023 12:42AM

Reassigned to mo...@google.com.

Hi, I updated my version to alpha12 but still have these crashes. Please release a fix asap.

AnimateToStartAlpha03.zip

108 KB

Download

mo...@google.com <mo...@google.com> Nov 8, 2023 10:21PM

Accepted by mo...@google.com.

mo...@google.com <mo...@google.com> #9Nov 9, 2023 12:14AM

Will there be fixes released this Wednesday?

mo...@google.com <mo...@google.com> #10Nov 9, 2023 06:18PM

Hey, there is no release on Wednesday (holiday in the USA)

We haven't found the root cause of this exception, it happens when SQLite can't commit the transaction because some other connection has a lock, we need more information, a sample project that reproduces the issue preferably, or more details on how the database is being used (is it from multiple process? is there heavy concurrency?).

You can also increase the time SQLite will wait before it error with 'database locked' by executing PRAGMA busy_timeout = <time in ms>, the current default is 3000

ap...@google.com <ap...@google.com> #11Nov 10, 2023 11:27PM

Marked as fixed.

Thank you for you response.

Isn't these pull request addressed this issue? 1.1 https://android-review.googlesource.com/c/platform/frameworks/support/+/3408679 1.2 https://android-review.googlesource.com/c/platform/frameworks/support/+/3114928
According to RoomDB documentation about withTransaction: "Room will only perform at most one transaction at a time, additional transactions are queued and executed on a first come, first serve order." So the transaction should just wait for other transaction to complete and not throw exception instead. Isn't it?

pr...@google.com <pr...@google.com> #12Nov 29, 2023 09:39PM

I tried to use this code and still getting the same error from users. (deferredTransaction instead of immediateTransaction)

private val dbMutex = Mutex()

suspend fun <R> MyDatabse.workaroundWithTransaction(block: suspend TransactionScope<R>.() -> R) {
    dbMutex.withLock {
        useWriterConnection {
            it.deferredTransaction(block)
        }

        // TODO: Fix https://issuetracker.google.com/issues/340606803#comment2
        // Manually triggers invalidation
        invalidationTracker.refreshAsync()
    }
}