Feature Request / 功能请求
Describe the Feature Request / 描述功能请求
在基于资源池执行业务流程的场景中，当前系统通常采用"随机分配下一个可用资源"的策略。这种策略在业务成功时没有问题，但当某个业务实例因 transient 失败（网络抖动、第三方服务超时、临时风控等）而失败时，用户往往希望用同一个资源重新跑一次，而不是被随机分配到另一个资源。
具体痛点：
- 失败后没有便捷入口让用户"用刚才失败的那个资源再试一次"。
- 资源的历史失败原因、失败次数没有持久化展示，用户无法判断该资源是否值得重试。
- 批量自动调度模式下，系统只按"下一个可用资源"调度，缺少"优先重试近期失败资源"的策略。
- 当失败被判定为环境/网络类错误时，资源本身仍然有效，直接丢弃或降级会降低整体成功率。
因此，希望支持"指定 claim 指定资源"的能力，让业务重试更加可控、可观测、可闭环。
Describe Preferred Solution / 描述首选解决方案
-
失败资源一键重试
- 在任务/资源列表中，对失败状态的记录提供"重试此资源"操作。
- 点击后，系统自动将历史失败资源的标识回填到"指定资源"输入框并触发新一轮业务流程。
- 重试时默认进入"严格模式"：若该资源已被占用或不可用，直接报错，不再自动 fallback 到其他资源。
-
失败统计与原因落库
- 在资源元数据或独立重试统计表中，记录每个资源的：失败次数、最近一次失败原因、最近一次失败时间、历史成功次数。
- 前端列表展示"失败次数"等字段，帮助用户快速识别"资源本身异常"与"环境异常"。
-
自动调度增加"失败优先"策略
- 在自动批量调度配置中增加开关：
优先重试近期失败的资源。
- 开启后，调度器在随机 claim 下一个可用资源之前，先尝试 reclaim 一个最近一段时间内失败、且失败原因属于可重试类别（如网络超时、服务临时不可用）的资源。
- 对不可重试类失败（如资源被封禁、认证永久失效）的资源保持隔离，避免无效循环。
-
严格指定模式
- 当用户通过"重试"按钮或手动填写资源标识触发时，默认开启严格模式。
- 严格模式下，若指定资源不可用，流程立即失败并给出明确提示，防止无感知换号导致业务数据不一致。
-
对外接口补充（可选）
- 提供重置并立即重试某个资源的原子接口，避免业务侧先 reset 再触发两次调用。
- 提供资源重试历史查询接口，支持外部系统做更复杂的重试策略决策。
Describe Alternatives / 描述替代方案
- 方案 A（最小改动）：仅暴露失败统计与历史原因，重试入口仍由用户手动复制资源标识并触发。实现成本低，但操作不够闭环。
- 方案 B（仅加一键重试）：不改造自动调度，只在列表加"重试此资源"按钮。适合小批量人工运营场景。
- 方案 C（外部编排）：由上游业务系统自行维护失败资源列表，通过现有 reset + claim 接口编排重试。缺点是会把失败原因等上下文丢失在 reset 动作中。
建议先落地方案 A + 一键重试按钮，再视情况扩展自动调度策略。
Related Code / 相关代码
- 资源调度模块：负责
claim_next() / claim_by_id() / release() 等原子操作。
- 业务执行模块：负责执行业务流程并返回结果或异常。
- 状态管理模块：负责维护资源状态（available / in_use / done / failed）及失败原因。
- 前端页面：资源列表、任务列表、触发入口、自动调度配置面板。
Additional Context / 附加上下文
- 典型业务场景：批量任务执行、账号注册/激活、接码/接码平台对接、优惠券核销、外部 API 调用等，都可能在 transient 失败后希望用同一资源重试。
- 与现有功能关系：
- 若已有"资源重置"功能，重试不应直接清空历史失败原因，而应追加到重试历史中。
- 若已有"指定资源"输入框，应支持从失败记录一键回填，减少人工操作。
- 建议新增/扩展接口：
POST /resources/{id}/retry：重置并立即用该资源启动一次新业务实例。GET /resources/{id}/retry_history：返回该资源的成功/失败时间线。- 自动调度配置中新增
retry_failed_first: bool 与 retryable_error_patterns: list[str]。
If the feature request is approved, would you be willing to submit a PR? / 如果功能请求被批准，你愿意提交 PR 吗？
Yes / 是（如需帮助提交 PR，可以提供协助）
Feature Request / 功能请求
Describe the Feature Request / 描述功能请求
在基于资源池执行业务流程的场景中，当前系统通常采用"随机分配下一个可用资源"的策略。这种策略在业务成功时没有问题，但当某个业务实例因 transient 失败（网络抖动、第三方服务超时、临时风控等）而失败时，用户往往希望用同一个资源重新跑一次，而不是被随机分配到另一个资源。
具体痛点：
因此，希望支持"指定 claim 指定资源"的能力，让业务重试更加可控、可观测、可闭环。
Describe Preferred Solution / 描述首选解决方案
失败资源一键重试
失败统计与原因落库
自动调度增加"失败优先"策略
优先重试近期失败的资源。严格指定模式
对外接口补充（可选）
Describe Alternatives / 描述替代方案
建议先落地方案 A + 一键重试按钮，再视情况扩展自动调度策略。
Related Code / 相关代码
claim_next()/claim_by_id()/release()等原子操作。Additional Context / 附加上下文
POST /resources/{id}/retry：重置并立即用该资源启动一次新业务实例。GET /resources/{id}/retry_history：返回该资源的成功/失败时间线。retry_failed_first: bool与retryable_error_patterns: list[str]。If the feature request is approved, would you be willing to submit a PR? / 如果功能请求被批准，你愿意提交 PR 吗？
Yes / 是（如需帮助提交 PR，可以提供协助）