IssueTracker

Component used: work-runtime-ktx Version used: 2.7.1 Devices/Android versions reproduced on: N/A

The documentation page says:

(source: https://developer.android.com/topic/libraries/architecture/workmanager/how-to/managing-work?#stop-worker)

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

• You explicitly asked for it to be cancelled (by calling WorkManager.cancelWorkById(UUID), for example).
• In the case of unique work, you explicitly enqueued a new WorkRequest with an ExistingWorkPolicy of REPLACE. The old WorkRequest is immediately considered cancelled.
• Your work's constraints are no longer met.
• The system instructed your app to stop your work for some reason. This can happen if you exceed the execution deadline of 10 minutes. The work is scheduled for retry at a later time.

Under these conditions, your Worker is stopped.

My questions are about clearing up the last 2 bullet points.

When is the worker stopped when constraints are no longer met? Instantly? E.g. if there is a network connection constraint and the network connection drops (e.g. for a millisecond, or a second, or a minute, or a week), when is the worker stopped? That is not clear from the documentation. I'm assuming that the stop command is instant, because it's not specified. Is that correct? Consider specifying this.

The last bullet point mentions explicitly that work is scheduled for retry. Does that implicitly mean that work is not scheduled for retry after it's stopped when constraints are no longer met? Consider explicitly making this clear.

Side note: if stopped work after constraints are no longer met doesn't restart even when the constraints are met again, then this would break the guarantee that WorkManager ensures that work runs. This implicitly means that stopped work should restart when constraints are met again, but the linked documentation page fails to mention this. Hence my doubt, and this issue/question.