Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Can you show me the code you are using to build/enqueue your work? This is definitely surprising - I wonder if you have an incredibly deep hierarchy, or if there's some kind of circular dependency (which we should be catching).
ap...@google.com <ap...@google.com> #3
Unfortunately, the stack trace isn't telling us *which* work is causing the problem. My best guess is that it's this one, as it's the newly introduced worker on the build that is crashing, and other builds that don't include it aren't reporting the same crash:
fun enqueueWork(objects: List<MyType>) {
val inputData = Data.Builder().putString(MY_EXTRA, objects.serializeToJson())
val request = OneTimeWorkRequest.Builder(WORKER_CLASS)
.setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
.setInputData(inputData.build())
.addTag(WORK_TAG)
.build()
val workManager = WorkManager.getInstance()
workManager.beginUniqueWork(WORK_ID, ExistingWorkPolicy.APPEND, request).enqueue()
}
The enqueueWork method is being called at the end of an RxJava chain that's using a buffer that's flushed every 5 minutes, or when an action is called.
fun enqueueWork(objects: List<MyType>) {
val inputData = Data.Builder().putString(MY_EXTRA, objects.serializeToJson())
val request = OneTimeWorkRequest.Builder(WORKER_CLASS)
.setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
.setInputData(inputData.build())
.addTag(WORK_TAG)
.build()
val workManager = WorkManager.getInstance()
workManager.beginUniqueWork(WORK_ID, ExistingWorkPolicy.APPEND, request).enqueue()
}
The enqueueWork method is being called at the end of an RxJava chain that's using a buffer that's flushed every 5 minutes, or when an action is called.
il...@google.com <il...@google.com> #4
How often are those actions being called? Any idea how big this chain is?
Description
Component used: Lifecycle
Version used: 2.5.0-alpha01
Currently the call to
enableSavedStateHandles()
creates aViewModel
using theViewModelStore
. This requires that the ViewModelStore be set on any component attempting to make the call, but there are scenarios where the call toenableSavedStateHandles
needs to happen before that in particular in the Fragment and Navigation components where the call is not immediately made when the object is constructed or sometimes not at all.If we remove the reliance on
SavedStateHandles
(and therefore view models), we can lean into theSavedStateProvider
APIs and the call toenableSavedStateHandles()
can be made before theViewModelStore
is set.