fix(orchestrator): envd error responses truncated to 100 chars, hiding root cause in logs and error chain
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- go
- Bereich
- backend, infrastructure
Rechercherichtung
Lesen Sie packages/orchestrator/pkg/sandbox/envd.go und untersuchen Sie die vier envd-Fehler- und Logging-Aufrufstellen, die im Issue identifiziert wurden. Überprüfen Sie, wie Response-Bodies in zurückgegebene Fehler und Logs einfließen, und bestätigen Sie anschließend, dass die abgeschlossene Änderung den vollständigen diagnostischen Body an jeder Stelle ohne Kürzung bewahrt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Problem
In packages/orchestrator/pkg/sandbox/envd.go, all envd error-response bodies are truncated to 100 characters via utils.Truncate(string(body), 100) before being embedded in fmt.Errorf strings and log fields:
```go
// line 182 — callEnvdCollapse
fmt.Errorf("collapse returned %d: %s", resp.StatusCode, utils.Truncate(string(body), 100))
// line 208 — postEnvd (covers /init, /pause, /resume, …)
fmt.Errorf("%s returned %d: %s", path, resp.StatusCode, utils.Truncate(string(body), 100))
// line 287 — CallEnvdUpgrade
fmt.Errorf("upgrade returned %d: %s", resp.StatusCode, utils.Truncate(string(body), 100))
// line 496 — initEnvd log field
zap.String("response_body", utils.Truncate(string(body), 100))
```
Because lines 182, 208, and 287 inject the truncated string directly into the error value, the truncation propagates all the way up the error chain and surfaces to callers as:
```
failed to create sandbox: failed to wait for sandbox start: failed to init new envd: /init returned 400: failed to mount "7e22c38a-5584-4730-8c31-449f5058ea19": failed to chroot into "/data1/orchestrator/vo
```
The message is cut mid-path, losing the actual root cause.
Impact
NFS volume mount failures are a concrete example. The full error body from envd is ~300 characters:
```
failed to mount "7e22c38a-5584-4730-8c31-449f5058ea19": failed to chroot into "/data1/orchestrator/volumes/team-f0796066-fb0b-4ea7-a9fe-613e9b8831bb/vol-885b64ff-686d-4f5c-b16d-eb4d5f9cd577": failed to bind mount "/data1/orchestrator/volumes/team-f0796066-fb0b-4ea7-a9fe-613e9b8831bb/vol-885b64ff-686d-4f5c-b16d-eb4d5f9cd577": no such file or directory
```
At 100 characters the message is truncated to:
```
failed to mount "7e22c38a-5584-4730-8c31-449f5058ea19": failed to chroot into "/data1/orchestrator/vo
```
The operator cannot tell from orchestrator logs or the returned error whether the failure is a missing directory, a permission issue, an NFS timeout, or something else. Diagnosing the root cause requires cross-referencing a completely separate service's logs (the NFS proxy).
Fix
Remove utils.Truncate from the four error-path call sites. envd error response bodies are short diagnostic strings generated by the server, not arbitrary user data, so there is no log-explosion risk.
PR: #3481
- Vorherrschende Sprache
- Go
- Sterne
- 1.6k
- Forks
- 448
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus e2b-dev/runtime
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running stateOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 86/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in e2b-dev/runtime
Ähnliche Issues
-
bug needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
netdata/netdata#24062 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
meshery/meshery#22119 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
automation documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag