IssueTracker

Component used: androidx.work
Version used: 2.8.1
Devices/Android versions reproduced on: Android S (API 32)

I've observed WorkManager behavior breaking down when there are large numbers of workers. The particular scenario that I investigated involved ~2000 unconstrained periodic workers, each with a period of 1 day. In this situation, a couple of specific misbehaviors were evident:

1. Newly-scheduled expedited workers did not run immediately as expected (or even within a few minutes) even though the app is in the foreground and their constraints were met
2. WorkManager itself fails to respond to the androidx.work.diagnostics.REQUEST_DIAGNOSTICS broadcast.

I believe WM uses its own work-scheduling APIs internally for responding to the REQUEST_DIAGNOSTICS broadcast, so of course these might just be the same underlying issue. It feels like a crowding-out problem: that when there is a great deal of potentially runnable work, newly-scheduled work simply isn't considered in a timely way even when that work is marked as expedited. (The fact that expedited work does not appear to take precedence here also feels like a bug.)

A background issue here is that arguably there should not be API for scheduling non-unique periodic work. enqueuePeriodicWork() should not exist.

The scenario I described here arose because a developer who was new to the WM API mistakenly used enqueuePeriodicWork() instead of enqueueUniquePeriodicWork(); so over time the app scheduled a large number of duplicates. An app that genuinely wants to schedule multiple periodic workers with the same parameters & constraints and the same implementation class can already do so via enqueueUniquePeriodicWork() by synthesizing a new tag for each desired new instance. So, removing enqueuePeriodicWork() wouldn't eliminate any actual capability -- it would just make it impossible for developers to accidentally shoot themselves in the foot like this.