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

オープン
#471 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
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

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。