[PR #246] [MERGED] template: report failed build steps by number, not instruction text #287

New issue

Closed

opened 2026-10-29 14:21:50 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:21:50 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/kvcache-ai/AgentENV/pull/246
Author: @nblintao
Created: 9/4/2026
Status: ✅ Merged
Merged: 9/7/2026
Merged by: @LSX-s-Software

Base: main ← Head: fix/build-step-index

📝 Commits (2)

41b31cd template: report failed build steps by number, not instruction text
5e3b497 template: number failed steps by their client-visible position

📊 Changes

3 files changed (+144 additions, -11 deletions)

View changed files

📝 src/api/impls/template_helpers.rs (+39 -2)
📝 src/template/build_spec.rs (+26 -0)
📝 src/template/step_executor.rs (+79 -9)

📄 Description

What happens today

When a template build step fails, AgentENV fills BuildStatusReason.step with the instruction text ("RUN apt-get update && …", src/template/step_executor.rs). The official e2b Python SDK resolves that field as an index into its locally recorded stack traces — get_build_step_index maps "base" → 0, "finalize" → last, and otherwise calls int(step) with no fallback (packages/python-sdk/e2b/template/utils.py). So any failed build crashes the SDK's error path:

ValueError: invalid literal for int() with base 10: 'RUN apt-get update && …'

…and the real build error (already carried in message) is never raised. The JS SDK doesn't crash but silently loses the traceback (Number(step) → NaN).

The contract

The OpenAPI spec leaves step an unconstrained string ("Step that failed"), but e2b Cloud fills it with the 1-based step number (e2b-dev/infra, packages/orchestrator/pkg/template/build/phases/utils.go: strconv.Itoa(*StepNumber), numbered from 1 in phases/steps/factory.go), with "base"/"finalize" for those phases — and both official SDKs hard-code exactly that mapping. De-facto, numeric-or-sentinel is the contract.

Change

reason.step now carries the 1-based step number as a string.

The instruction text moves into message, next to the exit status and stderr it already reports:

message: "build step failed: RUN apt-get update …: command exited with status 100; stderr: …"
step:    "3"

Failures outside the step executor (base image, pipeline) keep step: None, which both SDKs skip safely.
Existing test updated; new test pins the 1-based position of a failing RUN.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/kvcache-ai/AgentENV/pull/246 **Author:** [@nblintao](https://github.com/nblintao) **Created:** 9/4/2026 **Status:** ✅ Merged **Merged:** 9/7/2026 **Merged by:** [@LSX-s-Software](https://github.com/LSX-s-Software) **Base:** `main` ← **Head:** `fix/build-step-index` --- ### 📝 Commits (2) - [`41b31cd`](https://github.com/kvcache-ai/AgentENV/commit/41b31cdb1f363018b5d92c8222d1336e443be5fd) template: report failed build steps by number, not instruction text - [`5e3b497`](https://github.com/kvcache-ai/AgentENV/commit/5e3b497d51064fbde5325d10b4b77b0d6bc9d8c0) template: number failed steps by their client-visible position ### 📊 Changes **3 files changed** (+144 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `src/api/impls/template_helpers.rs` (+39 -2) 📝 `src/template/build_spec.rs` (+26 -0) 📝 `src/template/step_executor.rs` (+79 -9) </details> ### 📄 Description ## What happens today When a template build step fails, AgentENV fills `BuildStatusReason.step` with the instruction text (`"RUN apt-get update && …"`, `src/template/step_executor.rs`). The official e2b Python SDK resolves that field as an index into its locally recorded stack traces — `get_build_step_index` maps `"base"` → 0, `"finalize"` → last, and otherwise calls `int(step)` with no fallback (`packages/python-sdk/e2b/template/utils.py`). So any failed build crashes the SDK's error path: ``` ValueError: invalid literal for int() with base 10: 'RUN apt-get update && …' ``` …and the real build error (already carried in `message`) is never raised. The JS SDK doesn't crash but silently loses the traceback (`Number(step)` → `NaN`). ## The contract The OpenAPI spec leaves `step` an unconstrained string ("Step that failed"), but e2b Cloud fills it with the **1-based step number** (`e2b-dev/infra`, `packages/orchestrator/pkg/template/build/phases/utils.go`: `strconv.Itoa(*StepNumber)`, numbered from 1 in `phases/steps/factory.go`), with `"base"`/`"finalize"` for those phases — and both official SDKs hard-code exactly that mapping. De-facto, numeric-or-sentinel is the contract. ## Change - `reason.step` now carries the 1-based step number as a string. - The instruction text moves into `message`, next to the exit status and stderr it already reports: ``` message: "build step failed: RUN apt-get update …: command exited with status 100; stderr: …" step: "3" ``` - Failures outside the step executor (base image, pipeline) keep `step: None`, which both SDKs skip safely. - Existing test updated; new test pins the 1-based position of a failing RUN. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-29 14:21:50 +00:00