Fixed
Status Update
No update yet.
Comments
il...@google.com
ap...@google.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ap...@google.com
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
ap...@google.com
just emitting same live data reproduces the issue.
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
ap...@google.com
With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)
ap...@google.com
yea sorry immediate does not fix it.
I actually have a WIP fix for it:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
I actually have a WIP fix for it:
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
https://android-review.googlesource.com/1112186
https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
ap...@google.com
Project: platform/frameworks/support
Branch: snap-temp-L04700000699849955
commit 12b13608ec1155b5780fe44f5ab07cdc93c5ba90
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1436750
Branch: snap-temp-L04700000699849955
commit 12b13608ec1155b5780fe44f5ab07cdc93c5ba90
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
ap...@google.com
Project: platform/frameworks/support
Branch: snap-temp-L69500000699869549
commit 7204d04ad74baf9816389e27778266391fbd79a5
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1436913
Branch: snap-temp-L69500000699869549
commit 7204d04ad74baf9816389e27778266391fbd79a5
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
ap...@google.com
Project: platform/frameworks/support
Branch: snap-temp-L31300000699869852
commit 398a1fe7bb7792589189574aec5f6e77bb749229
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1436917
Branch: snap-temp-L31300000699869852
commit 398a1fe7bb7792589189574aec5f6e77bb749229
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
ap...@google.com
Project: platform/frameworks/support
Branch: snap-temp-L53700000699921463
commit 31027c16ff20b10e78093f8de205c81fc49dfc92
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1436920
Branch: snap-temp-L53700000699921463
commit 31027c16ff20b10e78093f8de205c81fc49dfc92
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
ap...@google.com
Project: platform/frameworks/support
Branch: snap-temp-L25200000699921867
commit 63e58ff4f522eb70dec6c0749679fb6b963698d8
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1436924
Branch: snap-temp-L25200000699921867
commit 63e58ff4f522eb70dec6c0749679fb6b963698d8
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
ap...@google.com
Project: platform/frameworks/support
Branch: snap-temp-L07700000699933785
commit 56fe0d47de20fb430c4280332a20eb96076dd44b
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1436929
Branch: snap-temp-L07700000699933785
commit 56fe0d47de20fb430c4280332a20eb96076dd44b
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 16:10:06 2020
Mention the current destination in getBackStackEntry errors
Improve the debugging experience for "No destination
with ID..." errors in getBackStackEntry() by mentioning
exactly destination the NavController is on. This would
allow developers to know if they have called popBackStack()
to a destination they don't expect to be at or if
they have not called setGraph() at all (where the
current destination would be null).
Test: existing tests pass
BUG: 168311416
Change-Id: Ia96b6732d7caadbddf31b7f35a1a419407ff6e25
(cherry picked from commit d0a10be065a3a629e3835f28d35804c91d8d2e4d)
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
vi...@gws.hotstar.com
getting this error even after ensuring we are setting graph before using it..
Caused by java.lang.IllegalArgumentException
No destination with ID 2131427956 is on the NavController's back stack in HiltNavGraphViewModelLazy.kt:49) , we are using androidx.hilt:hilt-navigation-fragment:1.0.0
androidx.navigation.NavController.getBackStackEntry (NavController.kt:2204)
androidx.hilt.navigation.fragment.HiltNavGraphViewModelLazyKt$hiltNavGraphViewModels$backStackEntry$2.invoke (HiltNavGraphViewModelLazyKt.java:49)
$special$$inlined$hiltNavGraphViewModels$4.invoke (HiltNavGraphViewModelLazy.kt:49)
is there any way to prevent it?
Caused by java.lang.IllegalArgumentException
No destination with ID 2131427956 is on the NavController's back stack in HiltNavGraphViewModelLazy.kt:49) , we are using androidx.hilt:hilt-navigation-fragment:1.0.0
androidx.navigation.NavController.getBackStackEntry (NavController.kt:2204)
androidx.hilt.navigation.fragment.HiltNavGraphViewModelLazyKt$hiltNavGraphViewModels$backStackEntry$2.invoke (HiltNavGraphViewModelLazyKt.java:49)
$special$$inlined$hiltNavGraphViewModels$4.invoke (HiltNavGraphViewModelLazy.kt:49)
is there any way to prevent it?
al...@gmail.com
Could we further improve this by indicating the name of the destination instead of just the ID number?
jb...@google.com
If you use a resource to provide the name it will already be displayed. Along with any route or label you may have added.
sh...@gmail.com
We are also getting this error even after ensuring we are setting the graph before using .popBackStack().
Is there any way to safeguard against this? I am not able to reproduce the error myself, but get a lot of errors show up in Crashlytics
Is there any way to safeguard against this? I am not able to reproduce the error myself, but get a lot of errors show up in Crashlytics
wm...@gmail.com
I have the same problem
ze...@gmail.com
Same here. It is not fixed. Can you reopen and look again?
ir...@gmail.com
Same problem here
ji...@gmail.com
Same problem here
ru...@gmail.com
Same problem here
fa...@fob-solutions.com
Same problem here, currently using version 2.7.7
ev...@gmail.com
same problem here
Description
Version used: 2.3.0
While using `by navGraphViewModels`, my crash reporting reports an error when invoked
NavGraphViewModelLazy.kt line 56
Fatal Exception: java.lang.IllegalArgumentException: No destination with ID 2131296839 is on the NavController's back stack
at androidx.navigation.NavController.getBackStackEntry(NavController.java:1293)
at com.example.ExampleFragment$$special$$inlined$navGraphViewModels$1.invoke(NavGraphViewModelLazy.kt:56)
[...]
This is difficult to debug since the navGraphId that I pass in should theoretically always be in the NavController's back stack when navGraphViewModels is invoked. The error message could be improved by letting me know what IS available on the back stack or if the back stack is completely empty.