fix(python-sdk): log the local cause when a command stream is cancelled

[AdaAibaby]

Problem

When a command's output stream ends on the client side without an end event, the SDK leaves no trace of why. The server (envd) only records that the stream was cancelled — not the client-side reason — so a cancelled commands.run is invisible from the SDK logs.

This matters because envd runs the guest process on a context decoupled from the streaming RPC: cancelling the stream does not kill the process, it runs to completion. So the common failure mode is "the command exited 0 but its result was never collected", with the only evidence being an ambiguous server-side context canceled line.

Cancellation reaches this state through several client-side paths, none of which currently log:

• the consumer stops iterating early (break, an outer timeout/wait_for, a sibling task cancel, the caller exiting)
• explicit disconnect() (which deliberately leaves the command running)
• an RPC/transport error before the end event

Change

CommandHandle (sync) and AsyncCommandHandle now take the logger the sandbox was already constructed with (ConnectionConfig.logger) and record, at INFO, why the stream ended, tagged with the pid:

• explicit disconnect() — "command left running"
• consumer stopped iterating — the sync handle catches GeneratorExit; the async handle logs in disconnect() and in the error path of its reader task
• stream error before the end event — the error type and message

It is a no-op when no logger is configured (the default), so nothing changes for callers who did not opt into logging.

Scope

This is the client-side, first increment of #1877 (correlate SDK cancellations with envd logs). It intentionally does not yet introduce a shared request-id — the logs correlate by sandbox id + pid + timestamp with the server-side change e2b-dev/runtime#3647, which downgrades the client-cancel line from ERROR→INFO, fixes its status code, and annotates the cancel phase. The shared-id closing of the loop is tracked in #1877.

Testing

• All six changed files parse; ruff format --check passes; the added Optional[logging.Logger] parameter matches the existing Optional[...] convention in these files.
• No behaviour change for existing callers (logger defaults to None).

Related: #1877, e2b-dev/runtime#3647.

[changeset-bot]

🦋 Changeset detected

Latest commit: 628298c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
e2b	Patch
@e2b/python-sdk	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[devin-ai-integration]

TASTE.md review

Checked the changed code against the parity rules (T-1, T-2), API shape (T-3/T-3a, T-26), streaming (T-27–T-30), configuration (T-49–T-51), errors/messages (T-62) and docstring rules (T-69–T-71). The sync and async Python handles mirror each other correctly (T-2), the logger is read from ConnectionConfig rather than a new knob (T-49), and it is a no-op by default.

3 findings (1 body-only, 2 inline):

1. T-1 / T-2 — JS parity missing (not on a changed line). The three surfaces mirror each other 1:1. packages/js-sdk/src/connectionConfig.ts already carries logger, but packages/js-sdk/src/sandbox/commands/commandHandle.ts gets no equivalent "stream ended: " logging in disconnect() / the stream error path. Either add the JS half in this PR or say explicitly in the description that it is a follow-up (AGENTS.md also asks for equivalent JS changes when touching the SDK).
2. T-3a — the new logger parameter is a defaulted positional in both CommandHandle.__init__ signatures (inline, low severity since the constructors are internal per T-26).
3. T-62 — the sync handle can emit two contradictory "stream ended" lines for a single disconnect() (inline).

Not TASTE-related but worth noting: no test covers the new log lines and no changeset was added for the python-sdk behavior change (both requested by AGENTS.md).