IssueTracker

Component used: WorkManager
Version used: 2.10.0
Devices/Android versions reproduced on: Emulator

Observed behavior:
When a running Worker is updated with updateWork to change its constraints to values that are not satisfied at that current moment the worker keeps running.

Expected behavior:
The updated worker is cancelled if the new constraints are not satisfied.

This behavior doesn't match the documentation which reads:

There are a few different reasons your running Worker might be stopped by WorkManager:
...

• Your work's constraints are no longer met.

The observed behavior is also inconsistent with the situation when constraints themselves change while a Worker is running (e.g. network change) - the Worker will cancel if they are no longer satisfied.

Sample code:

// Schedule work to run on any network:
val anyNetworkConstraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()
val workRequestBuilder = PeriodicWorkRequestBuilder<MyWork>(...)
    .setConstraints(anyNetworkConstraints)

workManager.enqueueUniquePeriodicWork(
    MY_UNIQUE_WORK,
    ExistingPeriodicWorkPolicy.KEEP,
    workRequestBuilder.build()
)

// While the work is running on a metered network
// update the constraints to only run on unmetered network:
val myWorkId: UUID = /* get work id from WorkManager */
val umeteredNetworkConstraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.UNMETERED)
    .build()
val unmeteredWorkRequest = workRequestBuilder
    .setConstraints(unmeteredNetworkConstraints)
    .setId(myWorkId)
    .build()
workManager.updateWork(unmeteredWorkRequest)

// At this point constraints are not met but the Worker keeps running.

Real world example:
Many apps that transfer large amounts of data (e.g. podcast players, file synchronization) have a setting to select which network type to use for heavy transfers: any or unmetered. When the user changes the setting back and forth while exploring the app they risk that a background sync Worker gets started.
This potentially causes the user some cost, even if they realize their mistake immediately and change the setting back to "unmetered only" because the Worker will keep running.

This issue can be worked around by adding some logic to CANCEL_AND_REENQUEUE the existing Worker when UpdateResult is APPLIED_FOR_NEXT_RUN.