Fixed
Status Update
No update yet.
Comments
su...@google.com
That is the intended behavior because we have intended cancellation to be a permanent signal. That being said, we are investigating if we can relax this restriction so I will leave this bug open.
ma...@gmail.com
I completely agree with the idea that cancelling work should not end other enqueued work. It seems like it would be common for people to have work that needs to be in order, but individual work within that queue needs to be canceled. For example, in my situation I need uploads to happen in order, but if the user were to delete an entry related to that upload, I don't want to waste the users data uploading a file that I will have to clean up later.
su...@google.com
This API will be available in 2.4.0-alpha01 (which is not currently available publicly, but the code is on AOSP).
ko...@gmail.com
Tested with 2.5.0. Have two workers, second one was added with `APPEND_OR_REPLACE` when first one is not cancelled or failed yet, means second was added to the chain. Then first fails, the second one won't run as new chain even it was specified with `APPEND_OR_REPLACE`. Is that expected behavior?
My scenario: I need to execute sequentially workers regardless of previous worker status if it was cancelled or failed.
Please advice.
My scenario: I need to execute sequentially workers regardless of previous worker status if it was cancelled or failed.
Please advice.
ra...@google.com
That is expected. APPEND_OR_REPLACE is only applied during enqueue. It does not change the semantics of a chain of requests.
Description
Version used: 2.0.1
Devices/Android versions reproduced on: 25
I have a work "queue" defined by some string(`uniqueWorkName`) where I schedule different types of workers with netowrk constraints using `enqueueUniqueWork` and `ExistingPolicy.APPEND`.
Some of the workers may get cancelled before they run(no internet and user canceled the request during this thime). After I cancel ANY worker in the "queue", I am no longer able to submit any work there since everything after this gets marked CANCELED immideately on enqueuing.
Judgingby the code in `EnqueueRunnable.enqueueWorkWithPrerequisites` it is intended behaviour, but it shouldn't be. Why is CANCELING(not FAIL'ing) some of the work in the unique chain of work cancels the rest of them? It should only do so on FAILED jobs!