为流式任务设置总时限

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

流式评估一直发心跳，但没有最终结果。教学案例开始UTC10:00，总截止10:02；无活动超时另计。每次心跳重置唯一计时器会让任务无限占槽，需要独立总期限。

具体做法

开始时设不随流量重置的总截止，保留连接活动检测作为另一信号。到期停止本地等待，记timeout和实际尝试，释放本地容量；不得在期限后继续judge或重试。保留底层请求身份，远端是否仍运行、是否能取消单独核对，不能把本地race结束当取消成功。

反例

每次心跳都把两分钟重新计时，永远等待；本地超时后仍自动重试并把远端任务叫已取消。

改进写法

教学总截止固定10:02，心跳不延长。到期即停止本地等待，记录timeout而非业务零分，释放槽位；每次重试或后续判分前检查同一截止，期限后不再调用。底层请求身份和可能运行状态保留，按服务取消/对账能力另处理，不承诺Promise.race中止远端。

为什么这样改

心跳证明连接有活动，不能证明工作完成。总期限限制资源占用，deadline传播又避免一个已结束案例的后台重试继续产生调用。

如何验证

教学10:01仍有心跳、10:02无终态时应timeout；之后不能启动新重试或judge。检查本地槽位释放、远端状态未知分列，没有把timeout当任务得零分。

记录实际时间与请求身份，不编造已取消。本篇不调用流式服务。

适用边界

期限与恢复策略由任务决定，取消能力依实际客户端/服务。释放本地并发不等于释放远端资源，可能还有费用或副作用；冻结具体SDK/runner不提供当前保证。