Release v0.30.0

[lchoquel]

Release v0.30.0

Bumps version from 0.29.0 to 0.30.0. Promotes dev → main.

Changelog

Highlights

A run dispatched to a worker keeps the caller's request id. On pipelex 0.68.0, the lines a worker writes while it runs a POST /v1/execute run carry the request_id the response echoes, and the runtime's own span moves under pipelex.* on every log line.

Changed

• Pinned pipelex 0.68.0 (Breaking): up from ==0.67.0, exactly, the release whose execute accepts the inbound request id the host is serving. The .pipelex/ config shipped here already sits at the current schema, so no migration is required, but a deployment that selects the gcp log sink instead of json now refuses to boot when Google rejects its credentials, where it used to boot and lose every record in silence.
• A log line's trace keys name the host's span, and the runtime's span moves under pipelex.* (Breaking): trace_id, span_id and trace_flags now name the process's current OpenTelemetry span, which this server does not open, so they are absent unless the deployment runs it under OpenTelemetry instrumentation of its own. A line the runtime emits from inside a traced run carries the runtime's span as pipelex.trace_id and pipelex.span_id instead, so a query that joined lines to the runtime's exported spans on trace_id now joins on pipelex.trace_id.
• POST /v1/codegen stamps engine_version 0.68.0: the stamp is the pinned pipelex version, so a codegen.lock committed against 0.67.0 no longer matches until it is regenerated. POST /v1/build/runner carries the same stamp.

Fixed

• A distributed POST /v1/execute run's worker lines carry the request id: the route now puts the request id it resolved on the run's metadata, as POST /v1/start already did, so on a deployment whose orchestration_mode dispatches to a worker, such as temporal, the lines the worker writes while it runs the run's workflow and activities carry the request_id the response echoes. The logging page now says how the id reaches a worker's lines, and that a POST /v1/validate dispatched to a worker does not carry it yet.

Closes L-260927-1f98d3

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q8vvwyfhLh2jLYouEA6fBx

---

Summary by cubic

Promotes dev → main as release v0.30.0, pinning pipelex to ==0.68.0 and fixing request-id correlation so a POST /v1/execute run dispatched to a worker keeps the caller's request_id.

• POST /v1/execute now places the request id on the run's metadata, as /start already did, so the lines a worker writes while running the run's workflow and activities carry the request_id the response echoes.
• Breaking: a runtime line's own span now appears as pipelex.trace_id and pipelex.span_id; trace_id, span_id, and trace_flags name the host process's current OpenTelemetry span, which this server does not open, so they are absent unless the deployment instruments itself. Queries joining on trace_id must join on pipelex.trace_id.
• Breaking: POST /v1/codegen and POST /v1/build/runner stamp engine_version 0.68.0, so a codegen.lock committed against 0.67.0 no longer matches until regenerated.
• Breaking: selecting the gcp log sink now refuses to boot when Google rejects its credentials, where it used to boot and silently lose records.
• The logging page documents how a request id reaches worker lines and that POST /v1/validate dispatched to a worker does not carry it yet.

^{Written for commit e794629. Summary will update on new commits.}