Fixed
Status Update
No update yet.
Comments
jd...@xooloo.com
Hello,
We recently launched an update that includes "androidx.work:work-runtime:2.0.1", and we used it to schedule all our tasks now, in a satisfactory way. I just want to inform, (as you can see in the images attached below), that this problem keeps happening sporadically.
Keep in mind that the number of users affected in our case is small, since the app has several million active users, but it also starts to be worrisome, since the number of errors generated by each user is high.
The errors mainly occur in Android 6 and 7, and sometimes in 8, but especially in Android 7.
I do not expose implementation details, since the documentation of this SDK has been thoroughly studied, and in case there was a bad implementation, the number of errors would be infinitely greater.
Greetings.
PD: If you need any information that I can provide you, you just have to ask me.
We recently launched an update that includes "androidx.work:work-runtime:2.0.1", and we used it to schedule all our tasks now, in a satisfactory way. I just want to inform, (as you can see in the images attached below), that this problem keeps happening sporadically.
Keep in mind that the number of users affected in our case is small, since the app has several million active users, but it also starts to be worrisome, since the number of errors generated by each user is high.
The errors mainly occur in Android 6 and 7, and sometimes in 8, but especially in Android 7.
I do not expose implementation details, since the documentation of this SDK has been thoroughly studied, and in case there was a bad implementation, the number of errors would be infinitely greater.
Greetings.
PD: If you need any information that I can provide you, you just have to ask me.
du...@google.com
ap...@google.com
Thanks for re-uploading the screenshots.
A couple of questions:
* Can you reproduce this issue at all on your end ? If so, can you send us all WorkManager logs after turning on logging. For this you will have to use custom initialization and use Log.DEBUG. For more information look athttps://developer.android.com/topic/libraries/architecture/workmanager/advanced/custom-configuration
* Can you send us a breakdown of devices and total # of users affected ? The number of crashes will be dis proportionally high because once the app gets into this state - its hard to get out of it.
A couple of questions:
* Can you reproduce this issue at all on your end ? If so, can you send us all WorkManager logs after turning on logging. For this you will have to use custom initialization and use Log.DEBUG. For more information look at
* Can you send us a breakdown of devices and total # of users affected ? The number of crashes will be dis proportionally high because once the app gets into this state - its hard to get out of it.
Description
I'm using a custom PagingSource backed by a SparseArray and a RemoteMediator to feed the SparseArray when more items are needed and invalidates the PagingSource.
With the alpha08 version of Paging, I was having the same bug as the one reported by 172000108, but the insertSeparators function was working fine (I'm just displaying a header before each item).
With the snapshot version, it is not crashing anymore, but the insertSeparators is not inserting a header before the first item in the list.
It seems to me that it is related to the new terminatesStart function in Separators.kt on CombinedLoadStates. When I use a PagingSource generated by Room, it returns true, and the headers are all displayed.
But with a remote mediator, it returns false, that's why the first header might not displayed.
My remote mediator is first called with loadType REFRESH then with PREPEND (i always return endOfPaginationReached = true for this case, as I only append items). So the mediator.prepend of CombinedLoadStates is eventually terminal (first NotLoading(endOfPaginationReached = false) then NotLoading(endOfPaginationReached = true).
But my PagingSource is never called with a params Prepend (I would return an empty list and both null for prev and next keys if it was called). So source.prepend is never terminal (always NotLoading(endOfPaginationReached = false).