问题
Let's say we are developing a messaging app where we want to send messages into given conversations where the order of those messages is important in that conversation only, and if the app is put to the background, we want a guarantee that the message will be sent.
The WorkManager#beginUniqueWork method seems ideal for this, where the uniqueWorkName will be some conversation id, and ExistingWorkPolicy.APPEND will be used as the work policy to keep the work in the order scheduled.
So far in my application, as long as each piece of Work returns Result.SUCCESS, then any future scheduled work will be executed as expected. However, if one particular message fails to send in a fatal way and I return Result.FAILURE, then all future work with the same conversation id never seems to reach my implementation of Worker#doWork().
After digging through the source code of the EnqueueRunnable class, this seems like a very deliberate choice. What I can't really understand is why that is? It seems odd that if a uniqueWorkName fails, that that name becomes unusable for the rest of the life of the application (this persists across killing the app).
Furthermore, I'd like to know if anybody has a good solution to this, or knows if this will change in future versions of WorkManager. So far, the best thing I can think of is to return Result.SUCCESS but encode my own failure state in the output Data so that any observers of the work know it has failed. This however is a bit awkward and isn't very obvious for future maintainers of the code (and can be a bit confusing when watching the logs for a given piece of Work).
Perhaps my intended use of unique work is completely wrong and there's a better solution out there. Any ideas would be greatly appreciated, thanks!
回答1:
So I found the answer to my own question in this google issue tracker report.
Basically, unique work using the APPEND strategy creates a WorkContinuation where every new item is chained on as if we were to use the WorkContinuation#then method. Failing or cancelling the chain then cancels all downstream work, and so this is intended behaviour.
The ticket suggests 2 approaches:
If you really want APPEND's behavior, then another thing you could do is to check for WorkStatuses of the WorkRequests, and if (all of them happened to be cancelled) use REPLACE instead of APPEND. Bear in mind, this is inherently racy, because your WorkRequests might not have cancelled yet. So make sure you have some synchronization primitives around your use of WorkManager's APIs.
and
The simplest way to do this is to not actually return Result.FAILED; if you always return SUCCEEDED and return the actual pass/fail bit (if needed) in the output data, you can make sure the chain always keeps running.
Which is what I'm already doing. Hope this helps someone else.
来源：https://stackoverflow.com/questions/53033833/workmanager-why-does-failed-unique-work-with-the-append-existingwork-strategy