SDK user-function log correlation contract

SDK user-function log correlation contract

ADR 0157 defines the contract. The Go (#3444), JavaScript (#3445) and Python (#3446) SDKs implement it. See the Go, Node and Python references.

Field	Type	Meaning
run_id	string	Complete execution run ID.
function_id	string	Dispatch function ID, independent of logger name.
step_id	string	Exact durable step ID in an active scoped callback, otherwise "".
attempt	integer	Engine run attempt, or 0 when unknown.
trace_id	string	Valid current trace ID, or "" without a valid trace context.

The SDK logger enriches native records. Your logging configuration controls filtering, formatting, storage, and export. Native output needs no OTel provider. An OTel API or tracing provider alone does not enable Logs export.

OTel bridging is explicit. Go uses an application-selected slog handler, Node uses createOTelLogger over an application-provided OTel Logs logger, and Python uses an application-selected standard logging handler. The SDK creates no provider or exporter and does not install a second route beside your handler. An explicitly selected no-op sink may discard records.

A logger name identifies code, not the active span. OTel bridges receive the execution context to set intrinsic trace and span correlation as well as the five attributes. Valid unsampled trace contexts still correlate.

Logs inside memoized callbacks are not replayed. Logs outside durable callbacks can repeat on resume. Logs are not checkpointed and have no exactly-once promise. Go’s existing zero-argument callbacks retain their captured outer context; the accepted design adds explicit scoped callbacks for step logging.

SDK transport diagnostics remain separate from user-function records. Ironflow does not ingest user-function logs or expose them in platform log storage.