Fixed
Status Update
Comments
ra...@google.com <ra...@google.com> #2
Thanks for your patience with this bug. At this point you are just racing against JobScheduler itself. JobScheduler's book keeping. Unbinding a Job is asynchronous. So you if are creating jobs and completing jobs faster than JobScheduler can do book-keeping you are going to run against this limit.
JobScheduler's behavior is more deterministic on newer versions of the platform (O and above). So its harder to get close to this limit on these versions of the OS.
For your use-case, I suggest using a lower limit on the number of jobs you want WorkManager to schedule on your behalf. Use Configuration#setMaxSchedulerLimit() and use a limit << 100. I tried to reproduce your test case with a limit of 50, and we no longer exceed the scheduling limits.
In alpha08 we will clamp down the max limit to something more reasonable than 100 so developers don't race against the underlying scheduler.
JobScheduler's behavior is more deterministic on newer versions of the platform (O and above). So its harder to get close to this limit on these versions of the OS.
For your use-case, I suggest using a lower limit on the number of jobs you want WorkManager to schedule on your behalf. Use Configuration#setMaxSchedulerLimit() and use a limit << 100. I tried to reproduce your test case with a limit of 50, and we no longer exceed the scheduling limits.
In alpha08 we will clamp down the max limit to something more reasonable than 100 so developers don't race against the underlying scheduler.
ap...@google.com <ap...@google.com> #3
Okay, we will try setMaxSchedulerLimit 50. Thanks for your operative work.
Description
Version used: alpha09
Devices/Android versions reproduced on:
When using WorkContinuation.combine to join multiple works before continuing, it has a check in it to make sure it's acutally combining multiple WorkContinuations. I think this check is uneccessary and annoying, and adds a hard to find bug in implementations. The combine() method could easily just do nothing if there's only a single WorkContinuation passed to it.
Current use case:
I'm uploading a number of photos, which I'm splitting into a number of WorkContinuation lists so that several happen in parallel. If I only have one photo to upload then obviously I can only split this into one list of work, and the app crashes because WorkContinuation.combine() 'cannot' combine a single item. To fix this I have to have this code:
```
val allCombined = if (workLists.size == 1) workLists[0] else WorkContinuation.combine(workLists)
allCombined.then(....
```
which is much less nice than the original code which I think should work:
```
WorkContinuation.combine(workLists)
.then(....
```