Add Modal Sandbox instrumentation

[laminar-coding-agent]

Summary

• Add OpenTelemetry instrumentation for Modal Sandbox create and exec methods
• Capture spans with command, sandbox ID, timeout, and workdir attributes
• Emit stdout/stderr as OTel log records via tee-wrapped iterators (logs are emitted as the user reads output without consuming the data)
• Handle Modal's synchronicity pattern by instrumenting both public Sandbox and internal _Sandbox classes

Implementation

• New instrumentation module at opentelemetry/instrumentation/modal/ following the Daytona instrumentation pattern
• ModalSandboxInstrumentor registered in Instruments enum and INSTRUMENTATION_INITIALIZERS
• _TeeStreamIterator wraps ContainerProcess.stdout/stderr to emit logs transparently

Test plan

• ModalSandboxInstrumentor class instantiates and reports correct scope/dependencies
• All 4 wrapped functions (Sandbox.create, Sandbox.exec, _Sandbox.create, _Sandbox.exec) instrumented successfully via wrapt
• End-to-end test: created Modal sandbox, executed command, read stdout/stderr — all data passed through to user correctly
• Verified modal.sandbox.create and modal.sandbox.exec spans ingested into ClickHouse with correct input/output attributes
• Verified modal.log.stdout and modal.log.stderr logs ingested into ClickHouse with correct body and attributes
• Existing SDK tests (test_initialize.py) pass without regression

🤖 Generated with Claude Code

---

Note

Medium Risk
Adds a new auto-instrumentor and modifies shared tracing/log-emission utilities, including monkeypatching Modal ContainerProcess stream access, which could affect runtime behavior across different Modal versions. Changes also refactor Daytona log emission to a shared helper, so regressions could impact existing sandbox log capture.

Overview
Adds Modal Sandbox auto-instrumentation: new ModalSandboxInstrumentor wraps Sandbox.create/exec (sync + async) to emit spans with input/output attributes, and tees ContainerProcess.stdout/stderr so reading output produces modal.log.stdout/modal.log.stderr OTel log records.

Refactors sandbox log emission by introducing shared shared/log_emission.py (common LogStream + emit_log) and updating Daytona to use it. Extends shared/utils.py with safe_* helpers (no-op spans, safe end/is_recording/context) to make wrappers resilient to Laminar/OTel failures, and registers the new instrumentor via Instruments.MODAL and a corresponding initializer.

^{Reviewed by Cursor Bugbot for commit 7b3ead5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Rainhunter13]

@laminar-coding-agent

explain what is internal _Sandbox class and why instrumenting it brings any value

[laminar-coding-agent]

What is _Sandbox?

Modal uses the synchronicity library to auto-generate sync/async class pairs from a single implementation. _Sandbox is the internal async implementation class, while Sandbox is the public sync wrapper exposed to users.

Why instrument both?

synchronicity generates entirely separate method objects for each class:

• Sandbox.exec is a functools.partial
• Sandbox.create is a FunctionWithAio
• Neither shares a reference with _Sandbox.exec / _Sandbox.create

This means patching _Sandbox alone does NOT intercept calls made through the public Sandbox API (and vice versa). If we only instrumented Sandbox, async users calling _Sandbox methods directly (or Modal internals routing through _Sandbox) would produce no traces. If we only instrumented _Sandbox, sync callers using Sandbox would be missed.

We must instrument both classes to capture traces regardless of whether user code calls the sync or async interface.

I've updated the module docstring and inline comments in 4e13c23 to explain this clearly.

[laminar-coding-agent]

The CLAUDE.md already contains a well-written section on "Synchronicity-based SDKs (e.g. Modal)" that covers the key insight about _Sandbox vs Sandbox. The task was adding code comments to explain the same concept — no new non-obvious knowledge was discovered beyond what's already documented. Skipping the CLAUDE.md update.

[Rainhunter13]

@laminar-coding-agent

async users calling _Sandbox methods directly

It looks like Sandbox is a wrapper around Sandbox to handle both sync and async contexts. Users are using only public Sandbox class. Let's drop the _Sandbox instrumentation.

[laminar-coding-agent]

Done. Changes pushed:

• __init__.py: Removed the two _Sandbox WrappedFunctionSpec entries (async create/exec), updated the import to drop _awrap_create/_awrap_exec, and simplified the module docstring.
• wrappers.py: Removed _awrap_create and _awrap_exec async wrapper functions.
• CLAUDE.md: Removed the "Synchronicity-based SDKs" section about instrumenting _Sandbox separately.

Only the public Sandbox.create and Sandbox.exec (sync) are now instrumented.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f02d1eb. Configure here.}