struct-sdk 0.4.14__tar.gz → 0.4.15__tar.gz

{struct_sdk-0.4.14 → struct_sdk-0.4.15}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: struct-sdk
-Version: 0.4.14
+Version: 0.4.15
 Summary: Struct agent observability SDK — auto-instruments AI agent frameworks with OpenTelemetry
 Project-URL: Homepage, https://struct.ai
 Project-URL: Documentation, https://struct.ai/docs
@@ -862,6 +862,12 @@ before `init()`, call the contrib instrumentor directly (for example
 | Logs | Python `logging` records that reach the root logger, with trace context. The SDK's own and OpenTelemetry's records are excluded. With the `[structlog]` extra, structlog events that structlog writes itself (its default) are exported with their fields as attributes; events structlog hands to `logging` (`structlog.stdlib.LoggerFactory`) are exported once, through the `logging` bridge. Extras and structlog fields OpenTelemetry can't take as-is are exported as strings: dicts and mixed-type lists as JSON, everything else (UUIDs, datetimes, `None`, bytes) as its `str()`. Your other handlers still see the original values. With the `[exceptions]` extra, uncaught exceptions (main thread, other threads, asyncio) are exported as log records. If your app configures no logging, its warnings still print to stderr as they would without Struct. This is separate from `content_capture`, which only governs LLM content; disable `{"logging": {"enabled": False}}` and `{"structlog": {"enabled": False}}` (which also stops copies of your logs when Struct attaches to your OpenTelemetry setup), or redact attributes, if application logs can carry sensitive data. |
 | Metrics | Instrumentor metrics (for example `http.server.duration`) and process metrics (`process.cpu.*`, `process.memory.*`, threads, file descriptors, GC). Counters and histograms use delta temporality. |
 
+AWS calls through boto3/botocore or aiobotocore become one span per API
+operation (for example `S3.PutObject`), retries included, and carry the X-Ray
+header AWS services propagate. When Struct attaches to your existing
+OpenTelemetry setup, it instruments nothing, so AWS operation spans reach
+Struct only if your setup instruments botocore itself.
+
 Each instrumentor activates only when its library is installed.
 `instrumentation_options` disables or configures one by name; other keys are
 passed to that instrumentor:
@@ -894,8 +900,9 @@ them.
 ### Datadog ddtrace
 
 Under `ddtrace-run`, Struct leaves the libraries ddtrace patches to it, and
-`urllib3` beneath `requests` or `botocore`, to avoid duplicate spans and
-conflicting trace headers, and logs one INFO line listing them. Logs, process metrics, thread context, AI spans and libraries
+`urllib3` beneath `requests` or `botocore` (and `aiobotocore` when ddtrace
+patches `botocore`), to avoid duplicate spans and conflicting trace headers,
+and logs one INFO line listing them. Logs, process metrics, thread context, AI spans and libraries
 ddtrace doesn't patch still go to Struct. With `DD_TRACE_OTEL_ENABLED=true`,
 ddtrace's OpenTelemetry provider isn't the OpenTelemetry SDK, so full-app
 mode attaches nothing (an INFO line says so) and only AI spans reach Struct.

{struct_sdk-0.4.14 → struct_sdk-0.4.15}/README.md

@@ -746,6 +746,12 @@ before `init()`, call the contrib instrumentor directly (for example
 | Logs | Python `logging` records that reach the root logger, with trace context. The SDK's own and OpenTelemetry's records are excluded. With the `[structlog]` extra, structlog events that structlog writes itself (its default) are exported with their fields as attributes; events structlog hands to `logging` (`structlog.stdlib.LoggerFactory`) are exported once, through the `logging` bridge. Extras and structlog fields OpenTelemetry can't take as-is are exported as strings: dicts and mixed-type lists as JSON, everything else (UUIDs, datetimes, `None`, bytes) as its `str()`. Your other handlers still see the original values. With the `[exceptions]` extra, uncaught exceptions (main thread, other threads, asyncio) are exported as log records. If your app configures no logging, its warnings still print to stderr as they would without Struct. This is separate from `content_capture`, which only governs LLM content; disable `{"logging": {"enabled": False}}` and `{"structlog": {"enabled": False}}` (which also stops copies of your logs when Struct attaches to your OpenTelemetry setup), or redact attributes, if application logs can carry sensitive data. |
 | Metrics | Instrumentor metrics (for example `http.server.duration`) and process metrics (`process.cpu.*`, `process.memory.*`, threads, file descriptors, GC). Counters and histograms use delta temporality. |
 
+AWS calls through boto3/botocore or aiobotocore become one span per API
+operation (for example `S3.PutObject`), retries included, and carry the X-Ray
+header AWS services propagate. When Struct attaches to your existing
+OpenTelemetry setup, it instruments nothing, so AWS operation spans reach
+Struct only if your setup instruments botocore itself.
+
 Each instrumentor activates only when its library is installed.
 `instrumentation_options` disables or configures one by name; other keys are
 passed to that instrumentor:
@@ -778,8 +784,9 @@ them.
 ### Datadog ddtrace
 
 Under `ddtrace-run`, Struct leaves the libraries ddtrace patches to it, and
-`urllib3` beneath `requests` or `botocore`, to avoid duplicate spans and
-conflicting trace headers, and logs one INFO line listing them. Logs, process metrics, thread context, AI spans and libraries
+`urllib3` beneath `requests` or `botocore` (and `aiobotocore` when ddtrace
+patches `botocore`), to avoid duplicate spans and conflicting trace headers,
+and logs one INFO line listing them. Logs, process metrics, thread context, AI spans and libraries
 ddtrace doesn't patch still go to Struct. With `DD_TRACE_OTEL_ENABLED=true`,
 ddtrace's OpenTelemetry provider isn't the OpenTelemetry SDK, so full-app
 mode attaches nothing (an INFO line says so) and only AI spans reach Struct.

{struct_sdk-0.4.14 → struct_sdk-0.4.15}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "struct-sdk"
-version = "0.4.14"
+version = "0.4.15"
 description = "Struct agent observability SDK — auto-instruments AI agent frameworks with OpenTelemetry"
 readme = "README.md"
 requires-python = ">=3.10"
@@ -218,6 +218,15 @@ dev = [
     "google-cloud-bigquery>=3.30.0",
     "opentelemetry-instrumentation-grpc",
     "opentelemetry-propagator-b3",
+    # AWS client-operation suite (tests/test_aws_client_operations.py): real
+    # boto3 and aiobotocore clients, contrib's botocore instrumentor and the
+    # transport instrumentors beneath them (urllib3, aiohttp-client), against
+    # a local endpoint.
+    "boto3",
+    "aiobotocore",
+    "opentelemetry-instrumentation-botocore",
+    "opentelemetry-instrumentation-urllib3",
+    "opentelemetry-instrumentation-aiohttp-client",
 ]
 # The openai<3 suites: `uv run --no-default-groups --group openai2 pytest
 # tests/test_litellm.py tests/test_llamaindex.py` (pnpm run test:openai2).

{struct_sdk-0.4.14 → struct_sdk-0.4.15}/src/struct_sdk/_auto.py

@@ -132,8 +132,10 @@ _DDTRACE_INTEGRATIONS = {
 }
 
 # Transports beneath clients ddtrace patches: instrumenting one would overwrite
-# the traceparent ddtrace wrote on the same request.
-_TRANSPORT_BENEATH = {"urllib3": ("requests", "botocore")}
+# the traceparent ddtrace wrote on the same request. contrib's aiobotocore
+# instrumentor also wraps botocore's Endpoint.prepare_request, so it would write
+# Struct's X-Ray header on every botocore request ddtrace traces.
+_TRANSPORT_BENEATH = {"urllib3": ("requests", "botocore"), "aiobotocore": ("botocore",)}
 
 # Non-entry-point options handled here rather than by a contrib instrumentor.
 LOGGING = "logging"