Skip to content

wanghai-tech / hikoon-ACR

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 31194789 31194789e67b9ec1d457e54c5df0448ff82b0361 by cnb.bofCdSsphPA
Options

Make the FMA waiter durable enough for a real multi-hour transfer 

Constraint: The real dataset download lasts far longer than the waiter's original three-cycle lifetime, so the handoff process must survive unattended.
Rejected: Repeatedly restarting a short-lived waiter by hand | That is fragile and defeats the point of automation.
Confidence: high
Scope-risk: narrow
Directive: Keep the waiter long-lived by default and preserve progress logs so future sessions can see active polling immediately.
Tested: Diagnosed the original max-cycles behavior, ran a short two-cycle verification showing archive growth, then relaunched the long-lived waiter and confirmed live process plus log output.
Not-tested: The completed handoff path from full archive to extraction has not fired yet because the download is still in progress.
1 parent be2b3326
Inline Side-by-side
Showing 2 changed files with 226 additions and 5 deletions
......@@ -20,21 +20,42 @@ def inspect() -> dict:
def main():
parser = argparse.ArgumentParser()
parser.add_argument("--interval", type=float, default=30.0)
parser.add_argument("--max-cycles", type=int, default=3)
parser.add_argument(
"--max-cycles",
type=int,
default=0,
help="Number of polling cycles before exiting; 0 means wait indefinitely.",
)
args = parser.parse_args()
snapshots = []
for _ in range(args.max_cycles):
cycle = 0
while True:
cycle += 1
snap = inspect()
snapshots.append(snap)
print(
json.dumps(
{
"status": "polling",
"cycle": cycle,
"archive_size": snap.get("archive_size", 0),
"archive_bytes_expected": snap.get("archive_bytes_expected", 0),
"archive_progress_percent": snap.get("archive_progress_percent", 0.0),
},
ensure_ascii=False,
),
flush=True,
)
if snap.get("archive_size", 0) >= snap.get("archive_bytes_expected", 0):
result = json.loads(subprocess.check_output(POST, text=True))
print(json.dumps({"status": "completed", "snapshots": snapshots, "postdownload": result}, indent=2, ensure_ascii=False))
print(json.dumps({"status": "completed", "snapshots": snapshots, "postdownload": result}, indent=2, ensure_ascii=False), flush=True)
return
if args.max_cycles and cycle >= args.max_cycles:
print(json.dumps({"status": "waiting", "snapshots": snapshots}, indent=2, ensure_ascii=False), flush=True)
return
time.sleep(args.interval)
print(json.dumps({"status": "waiting", "snapshots": snapshots}, indent=2, ensure_ascii=False))
if __name__ == "__main__":
main()
......
......@@ -2,6 +2,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -969,6 +994,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -1146,6 +1196,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -1333,6 +1408,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -1510,6 +1610,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -1685,6 +1810,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -1858,6 +2008,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......@@ -2036,6 +2211,31 @@
## 2026-06-02
### Stage: 真实 FMA 等待器寿命缺陷修复
完成项：
- 诊断 `wait_for_fma_and_prepare.py` 掉线原因
- 确认原实现默认 `max-cycles=3`，约 90 秒后自然退出
- 修复为：`max-cycles=0` 时无限等待，并在每轮轮询输出进度日志
- 重新启动长期等待器并验证日志开始产生轮询输出
验证结果：
- 复检下载进度时已达到：
- `archive_size=3886596096`
- `archive_progress_percent=50.6094`
- 修复后执行：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 0.1 --max-cycles 2`
返回两轮 `polling`，并确认字节继续增长到：
- `3977117696 -> 3977314304`
- `51.7881% -> 51.7907%`
- 长期等待器已重新启动：
- `/usr/local/miniconda3/bin/python scripts/wait_for_fma_and_prepare.py --interval 30`
- 日志文件 `.omx_wait_for_fma.log` 已开始输出轮询 JSON
结论：
- 之前等待器掉线不是下载异常，而是脚本寿命设计过短
- 现在真实 FMA 链路已具备可长期驻留的自动等待与后处理能力
### Stage: 真实 FMA 守护链路掉线恢复
完成项：
......