IssueTracker

Thank you for reporting this And please provide below details for one feature which we need to consider as part of this bug:

Can you please explain in detail what exact you need (Be specific)?

* What is the desired behavior of the feature? (Be specific!)

* If relevant, why are current approaches or workarounds insufficient?

* If relevant, what new use cases will this feature will enable?

Same here, this sounds like a great feature! I'm pretty sure the issue template questions have already been addressed.

Hi everyone, we'll look into this.  In the meantime, please file WorkManager-specific bugs to "Android Public Tracker > App Development > Architecture Components > WorkManager".  We can triage the bugs and feature requests faster this way.  Thanks!

In the upcoming alpha03 release, Worker will have access to a new method, getRunAttemptCount(), that will return the current run count.  Based on this value, you can choose to return a different worker Result and possibly end execution.

The reason I didn't put it in the WorkerRequest.Builder as a max retry count is that it's not clear what State the work should enter if it exceeds the max retry count.  Should it be considered CANCELLED (which, so far, is a user-initiated state)?  Should it be considered FAILED (that seems wrong)?  I think it's better if the developer has control over this so that whatever State the work should be in at the end.

Same issue here!

The worst thing for me, beyond the crash itself, is that after it happens, there is NO WAY to recover. I removed most of the WorkManager code, but it keeps crashing (since tries to do the jobs, which it can't, on every start).

Yeah, you have to clear app data or disable the content provider in your manifest.

I also just filed this: https://issuetracker.google.com/79950952

Either WorkManager is too smart, or there is something wrong. I want to removeAll workers on my onCreate, and re-schedule myself everything later.
By cancelling-enqueuing I got into this snowball that ended with more than 100 jobs.

Sorry folks. This is a bug in alpha01. The fix should be a part of alpha02. Hang tight.

Do you know when the fix will be available?

We're aiming for later this week.

Awesome, I'll get to merge my branch! 😉

Hi, may I know,

1) After the end of execution of OneTimeWorkRequest typed worker's doWork(), do we need to cancelAllWorkByTag explicitly to perform "clean up"?

2) After this bug fixed, is there still any hard limit, only how many active job (with different tags) we can schedule on WorkManager?

Thanks.

No, you don't need to perform cleanup and no, there aren't any limits.

1. You don't need to perform any cleanup.  Completed OneTimeWorkRequests will not re-execute,
2. There is no limit on the number of jobs you can schedule; however, at most 100 will be sent to JobScheduler at a time.  The rest will be queued up and sent when appropriate.  (That being said, I would advise that you probably don't want to have hundreds of potentially active jobs at any one time.)

I still have this issue with 1.0.0-alpha02, like others it seems ( https://github.com/googlecodelabs/android-workmanager/issues/16 ).
As seen on the link, every time I restart my app (using ADB Idea plugin, that kill it then start it again), the numbers of tasks scheduled in JobScheduler increments by the number of periodic tasks scheduled.
I have 4 users that went into the issue and I will use a workaround code I wrote for now.
I see it on Samsung 7.0 devices for now.

Here's a sample project that reproduces the issue. I use ADB Idea Plugin with the "ADB Restart App" feature to triggers the issue.
You will see that with each restart, the jobcount from JobScheduler increases by 5, but not the one from WorkManager.
I hope someone will see this message, if I need to make another issue please tell me.

If your issue is specific to periodic work, I'd file a new issue since this one is a little different.