aws / aws/bedrock-agentcore-sdk-python
docs: /ping response requires undocumented `time_of_last_update` field — without it AgentCore silently reaps microVMs even when status is HealthyBusy
- 主要言語
- Python
- スター
- 761
- フォーク
- 147
- 平均マージ
- 1日 23時間
- マージ済み PR(30日)
- 7
説明
## Problem
The `/ping` contract documented at
[runtime-long-run.html](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-long-run.html)
and [runtime-troubleshooting.html](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-troubleshooting.html)
shows only:
{"status": "HealthyBusy"}
In practice, the platform's idle reaper requires a second field —
`time_of_last_update` — that the AWS-facing docs never mention.
Without it, `idleRuntimeSessionTimeout` fires at the configured
boundary even while `/ping` returns `HealthyBusy`, silently terminating
microVMs mid-execution.
The official SDK has emitted this field since the first public commit
(`4f5c80d`, 2025-07-15) — see
[`runtime/app.py:612`](https://github.com/aws/bedrock-agentcore-sdk-python/blob/main/src/bedrock_agentcore/runtime/app.py#L612).
A third-party post documents the full schema correctly:
https://eashank16.medium.com/demystifying-the-http-protocol-contract-for-amazon-bedrock-agentcore-runtime-30ae130485b4
## Reproduction (controlled, ~10 min)
1. Build a minimal ARM64 container with two endpoints:
- `/invocations`: spawn a background asyncio task, return `{"status":"accepted"}` immediately
2. `CreateAgentRuntime` with `lifecycleConfiguration: {idleRuntimeSessionTimeout: 60, maxLifetime: 28800}`
3. Invoke once. Observe CloudWatch:
- Pings continue every ~2s returning HealthyBusy
- Container is reaped at exactly +60s
Repeat with the only change being the ping body:
{"status": "HealthyBusy", "time_of_last_update": }
Container now survives indefinitely (verified to 256 s in our test).
## Other affected customers
- re:Post (May 2025): https://repost.aws/questions/QUXrgkw_c_QmC2m9fh-6LIzg/aws-bedrock-agentcore-issues — describes identical silent-restart symptom; AWS-bot answer recommends `HEALTHY_BUSY` pattern but doesn't
mention the field
- `aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore` PR #36 — merged a fix that returns `{"status": "HealthyBusy"}` without the field, almost certainly still broken under load
- Internal: we hit this on N=4 production agent runs across two AWS accounts before isolating it via the test above
## Asks
1. Update [runtime-long-run.html](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-long-run.html) and
[runtime-troubleshooting.html](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-troubleshooting.html)
to document the full ping schema (both fields, with semantics).
2. Either make the field optional on the platform side (so the
currently-documented contract works) or surface a clear error/warning
when a runtime returns a `/ping` body missing the field.
3. Patch the broken reference implementation in
`aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore` PR #36.
コントリビューションガイド
調査の方向性
runtime-long-run.html と runtime-troubleshooting.html の ping スキーマを runtime/app.py:612 の実装と比較します。ここで説明されている制御された 60 秒間の idleRuntimeSessionTimeout テストを使用して、ドキュメント化された動作と full-body の動作を再現し、その後 sample-host-openclaw PR #36 を確認します。ドキュメントが両方のフィールドを説明し、要求されたプラットフォームまたはリファレンス実装に関するフォローアップが解決されれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- aws, python
- 領域
- cloud, documentation
- issue の種類
- ドキュメント
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 42/100