Description / 描述
目前 astrbot_execute_shell 只有前台等待 30s 超时、和后台直接默默运行两种方式。这个设计在一些简单命令下够用,但对稍长一点的任务来说适用性比较窄,实际使用时很容易出现“前台超时了,但后台到底有没有继续跑、跑到哪了、是否已经结束”都无法确认的问题。
我认为这里至少需要补上一到两个能力:
- 增加 hook 工具,用于监听后台 shell 的运行状态和结果
- 增加
job_id,并提供对应的查询、列表读取能力
如果只保留“后台运行”每次都需要手动提醒检查结果。
Use Case / 使用场景
这个问题主要出现在执行时间不稳定、输出较多、或者需要确认最终结果的 shell 任务里。比如安装依赖、拉取仓库、下载模型、启动服务、执行构建脚本这类操作,经常会超过前台 30s 的等待时间。
当前一旦改成后台运行,调用方又没有办法继续跟踪任务状态,也不知道任务是否已经失败、卡住、还是其实已经执行完成。
Willing to Submit PR? / 是否愿意提交PR?
Code of Conduct
Description / 描述
目前
astrbot_execute_shell只有前台等待 30s 超时、和后台直接默默运行两种方式。这个设计在一些简单命令下够用,但对稍长一点的任务来说适用性比较窄,实际使用时很容易出现“前台超时了,但后台到底有没有继续跑、跑到哪了、是否已经结束”都无法确认的问题。我认为这里至少需要补上一到两个能力:
job_id,并提供对应的查询、列表读取能力如果只保留“后台运行”每次都需要手动提醒检查结果。
Use Case / 使用场景
这个问题主要出现在执行时间不稳定、输出较多、或者需要确认最终结果的 shell 任务里。比如安装依赖、拉取仓库、下载模型、启动服务、执行构建脚本这类操作,经常会超过前台 30s 的等待时间。
当前一旦改成后台运行,调用方又没有办法继续跟踪任务状态,也不知道任务是否已经失败、卡住、还是其实已经执行完成。
Willing to Submit PR? / 是否愿意提交PR?
Code of Conduct