platform/master
5
2
Fork 0
Code Issues 6 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Add tracing spans in Docker adapter and sandbox usecases #11

New issue
Closed
opened 2026-04-02 21:07:16 +00:00 by gglamer · 0 comments
gglamer commented 2026-04-02 21:07:16 +00:00
Owner
Copy link

Context

CreateSandbox, CleanupExpiredSandboxes, and DockerSandboxRuntime currently log key lifecycle events, but they do not emit tracing spans for sandbox orchestration steps.

Problem

This makes it hard to correlate:

  • create vs reuse vs replace decisions in the usecase layer
  • Docker create/stop/list operations in the adapter layer
  • sandbox startup failures and cleanup failures across layers

Proposal

Add tracing instrumentation behind existing observability ports:

  • usecase layer
    • CreateSandbox.execute
    • CleanupExpiredSandboxes.execute
    • optionally per-session cleanup path
  • Docker adapter layer
    • DockerSandboxRuntime.create
    • DockerSandboxRuntime.stop
    • DockerSandboxRuntime.list_active_sessions

Suggested span attrs

  • chat.id
  • session.id
  • container.id
  • sandbox.expires_at
  • sandbox.operation
  • sandbox.result
  • error.type

Notes

  • Keep clean architecture boundaries intact
  • Inner layers should depend only on the existing tracer port
  • Docker-specific tracing details must stay in adapter/docker/
  • Reuse noop tracer behavior when tracing is disabled

Done when

  • sandbox lifecycle operations are visible in traces
  • failures are attached to spans
  • tests are updated where tracing behavior affects constructor wiring or fakes
## Context `CreateSandbox`, `CleanupExpiredSandboxes`, and `DockerSandboxRuntime` currently log key lifecycle events, but they do not emit tracing spans for sandbox orchestration steps. ## Problem This makes it hard to correlate: - create vs reuse vs replace decisions in the usecase layer - Docker create/stop/list operations in the adapter layer - sandbox startup failures and cleanup failures across layers ## Proposal Add tracing instrumentation behind existing observability ports: - usecase layer - `CreateSandbox.execute` - `CleanupExpiredSandboxes.execute` - optionally per-session cleanup path - Docker adapter layer - `DockerSandboxRuntime.create` - `DockerSandboxRuntime.stop` - `DockerSandboxRuntime.list_active_sessions` ## Suggested span attrs - `chat.id` - `session.id` - `container.id` - `sandbox.expires_at` - `sandbox.operation` - `sandbox.result` - `error.type` ## Notes - Keep clean architecture boundaries intact - Inner layers should depend only on the existing tracer port - Docker-specific tracing details must stay in `adapter/docker/` - Reuse noop tracer behavior when tracing is disabled ## Done when - sandbox lifecycle operations are visible in traces - failures are attached to spans - tests are updated where tracing behavior affects constructor wiring or fakes
gglamer added this to the Tasks project 2026-04-02 21:07:30 +00:00
gglamer self-assigned this 2026-04-02 21:07:31 +00:00
gglamer added reference feat/minimal-docker 2026-04-03 06:49:53 +00:00
Sign in to join this conversation.
feat/minimal-docker
Branches Tags
Clear current reference
main
feat/network
feat/storage-s02-in-memory-metadata-repositories
feat/storage
dev
feat/minimal-docker
Clear current reference
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Tasks
Assignees
Clear assignees
No assignees
gglamer
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: platform/master#11
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?