关于运行出错后的处理

[yzbyzz]

ALAS 很好地解放了双手和时间，实现这个目的的关键因素是 ALAS 本身的稳定。个人觉得这里的稳定性有提升的空间。

目前我观察到的情况是 ALAS 在发现错误重复三次的时候，会停止运行。比如 每日 SP 活动，点击地图三次，如果发现不能进入（比如活动已经结束了），此时会触发错误，然后停止运行。
感觉这里发现错误后，可以将当前的任务延迟半小时或者其他时间再执行，继续执行队列中的其他任务。这样子可以在某些小问题出现的时候，降低出错的可能性。
当然，这里可以给不同的任务设置不同的重要性：关键任务执行失败后还是停止 ALAS（比如重启之类的任务）；非关键任务执行失败后只是将该任务延迟执行。

印象中之前看到一个 PR，是关于这方面的，不过当时应该是那个 PR 有些地方需要完善优化，所以没有合并。而原作者后面没有做相应的修改，也就一直没有合并该 PR。
这里想看看这种处理是否有问题？如果没有的话，是否有考虑实现这个功能呢？

[LmeSzinc]

#1033 #838

这个和很久以前的 838 都不理想，实现过于简单粗暴了，838当年合了，但是用户反馈说出错关任务最后被关了很多任务，然后就回退了。错误处理需要前端配合，并且在讨论出合理的方案之前都不做了。

现在还没有优雅的方案，你可以试着拟一个

[yzbyzz]

1033 这里看起来是一种不错的想法。我是这样考虑的

• 保持目前的情况，遇到错误时直接停止。
  • 这样子一旦遇到错误，就不能执行后面的任务。停止后 到 用户发现并重新启动的这段时间都会被跳过
• 遇到错误后，执行其他任务，延迟执行当前任务。
  • 发生错误 到 用户或开发者发现并解决问题的这段时间，其他任务仍旧可以执行
  • 这里需要类似 1033 一样，继续执行其他任务的同时，让用户明确看到有任务执行失败的。

我的理解是增加这样的处理后稳定性会提升，虽然看起来不算是很完美的方案。之前 838 的问题是否在于出错的任务显示不够明显呢？
我的理解是在 1033 的基础上进一步强化出错任务的显示。因为对这里前端相关 ui 不是很了解，一个粗浅的想法是出错时继续执行其他任务，但是出现一个弹窗，这样用户或者开发者在回来看 alas 时可以明显发现有出错的任务。
(不知道这里对 838 1033 的理解是否有问题。)