WorkManager：为什么使用“ APPEND” ExistingWork策略进行的唯一工作失败，为什么不允许使用相同名称进行更多工作？

Question

假设我们正在开发一个消息传递应用程序，我们希望将消息发送到给定的对话中，这些消息的顺序仅在该对话中很重要，并且如果该应用程序置于后台，我们希望保证消息将被发送。

该WorkManager#beginUniqueWork方法对此似乎是理想的，该方法uniqueWorkName将是一些对话ID，ExistingWorkPolicy.APPEND并将其用作工作策略以按预定顺序安排工作。

到目前为止，在我的应用程序中，只要每一项工作都返回Result.SUCCESS，那么将来任何计划的工作都将按预期执行。但是，如果一条特定的消息未能以致命的方式发送并返回Result.FAILURE，那么以后所有具有相同对话ID的工作似乎都无法实现Worker#doWork()。

在EnqueueRunnable仔细研究了类的源代码之后，这似乎是一个非常刻意的选择。我无法真正理解的是为什么呢？似乎很奇怪，如果uniqueWorkName失败，则该名称在应用程序的整个生命周期中都变得不可用（这在杀死该应用程序时一直存在）。

此外，我想知道是否有人对此有很好的解决方案，或者是否会在的将来版本中更改WorkManager。到目前为止，我能想到的最好的事情是返回Result.SUCCESS但在输出中编码我自己的失败状态，Data以便工作的任何观察者都知道它已经失败了。但是，这有点尴尬，对于将来的代码维护者来说不是很明显（并且在查看给定段的日志时可能会造成混淆Work）。

也许我原本打算使用独特作品的做法是完全错误的，并且有更好的解决方案。任何想法将不胜感激，谢谢！

Answer 1

因此，我在此Google问题跟踪器报告中找到了自己问题的答案。

基本上，使用该APPEND策略的独特工作会创建一个WorkContinuation链接每个新项目的地方，就像我们要使用该WorkContinuation#then方法一样。失败或取消链后，将取消所有下游工作，因此这是预期的行为。

凭单建议了两种方法：

如果您确实希望APPEND的行为，那么您可以做的另一件事是检查WorkRequests的WorkStatuses，如果（所有这些碰巧都被取消了）使用REPLACE而不是APPEND。请记住，这从本质上讲是合理的，因为您的WorkRequests可能尚未取消。因此，请确保您在使用WorkManager的API时具有一些同步原语。

和

最简单的方法是不实际返回Result.FAILED; 如果您始终返回SUCCEEDED并在输出数据中返回实际的通过/失败位（如果需要），则可以确保链始终保持运行状态。

这就是我已经在做的。希望这对其他人有帮助。