WorkManager 2.0.1中WorkContinuation组合行为异常咨询

嘿，这个场景我之前碰到过类似的情况，其实这是WorkManager 2.x版本中唯一任务（Unique Work）与Continuation绑定逻辑的预期行为，并不是Bug。下面给你拆解清楚原因：

核心逻辑：唯一任务的归属链是固定的 #

当你通过beginUniqueWork创建一个唯一任务时，这个任务实例会和它诞生的那条Continuation链牢牢绑定。具体到你的场景：

• 方式一中的UniqueWorker1属于第一条Continuation链（从beginUniqueWork("UniqueWorker")到then(finishingWorker)），它的完成信号只会触发这条链上的后续任务。
• 当你在方式二中调用beginUniqueWork("UniqueWorker1", ExistingWorkPolicy.KEEP, uniqueWorker1)时，WorkManager并没有新建UniqueWorker1，而是复用了方式一中已经存在的那个任务实例。但重点是：这个复用的任务不会和方式二中的新组合链建立关联——它的完成通知只会发给自己最初归属的那条链。

为什么方式二的FinishingWorker没被触发？ #

当UniqueWorker1重试成功后，它只会向自己的"原生"链（方式一的链）发送完成信号，触发对应的FinishingWorker。而方式二中的combine链，虽然看起来依赖了uniqueWorkContinuation1，但这个continuation对应的任务已经在运行中，WorkManager的组合逻辑不会去监听一个"已启动任务"的后续完成事件——combine只会监听那些在组合操作时才开始执行的子任务的状态变化。

补充说明你提到的"简单测试正常"的情况 #

你说简单测试里组合已存在任务逻辑正常，那应该是因为测试中的已存在任务在组合时已经处于完成状态了——这时combine会直接判定该子任务已完成，等其他任务结束后就触发后续。但你的场景里UniqueWorker1在组合时还处于重试等待状态（未完成），这就触发了"复用任务的完成信号仅归属初始链"的规则。

给你两个可行的解决方向 #

如果需要让方式二的FinishingWorker能正常触发，可以试试：

• 把方式二中的ExistingWorkPolicy.KEEP改成REPLACE：这样会创建新的UniqueWorker1实例，它会和方式二的组合链绑定，完成后就能触发后续的FinishingWorker。不过要注意，这会取消方式一中的UniqueWorker1任务。
• 手动触发逻辑：在方式一中的UniqueWorker1完成后，通过代码手动触发方式二中的任务流，不依赖WorkManager的自动链式触发。

内容的提问来源于stack exchange，提问作者Nominalista