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!