feature/Requestid-lost-worker · L-260925-d5b7ce - #100
Merged
Merged
Conversation
Move the pipelex pin from 0.67.0 to 0.68.0, the release whose PipelexMTHDSProtocol.execute accepts the inbound request id. The base method's new parameter made ApiRunner.execute an incompatible override, so it now takes request_id in the same position and forwards it to super().execute; the /execute route does not pass it yet. The release moves a log line's trace_id, span_id and trace_flags onto the process's current OpenTelemetry span and carries the runtime's span under pipelex.trace_id and pipelex.span_id, so docs/logging.md now says so. The changelog records the pin, that log-field change, the gcp sink's boot refusal and the codegen engine_version stamp moving to 0.68.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The /execute handler now passes request_id_of(request) to ApiRunner.execute, which forwards it to the runtime's execute, so the id lands on the run's RunMetadata. That is the payload a Temporal worker deserializes and binds its log context from; the middleware's in-process binding never reaches it, so until now every worker line of a distributed /execute run carried no request_id. /start already threaded it through pipeline_run_setup. The dispatch tests prove the payload rather than the call: the stub orchestrator records the dispatched job's RunMetadata.request_id, which carries an inbound X-Request-ID on a temporal deployment and the minted id otherwise. A route test mirrors the /start one. docs/logging.md now says how the id reaches a line in each process, and that a /validate dispatched to a worker does not carry it yet. It also finishes the trace-key rows the 0.68.0 pin changed, with when the pipelex.* pair appears and a paragraph on which key joins a line to exported Pipelex spans. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ment The worker binds the run's log context inside the workflow body and inside each activity that binds it, so the lines written there carry the request id. A line written outside those bindings does not: the Temporal SDK logs its "Completing activity as failed" warning after the activity's binding has exited. The changelog, docs/logging.md and docs/error-responses.md said every worker line carried the id; they now say the lines written inside the run's workflow and activities do, and name the SDK's line as one that does not. The /start route test's comment named JobMetadata.request_id and a WorkflowLog that no longer exist; the field is RunMetadata.request_id. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A `POST /v1/execute` run dispatched to a Temporal worker lost the request id: the worker binds its log context from the run's `RunMetadata`, and the route never put the id there. This moves the `pipelex` pin to 0.68.0, whose `execute` takes a `request_id`, and the `/execute` route now passes the id it resolved, as `/start` already did; the dispatch tests prove the id reaches the job the orchestrator is handed. The logging page now says how the id reaches a worker's lines and where it does not yet, and describes the trace keys 0.68.0 writes, including the new `pipelex.trace_id` and `pipelex.span_id`.
Closes L-260925-d5b7ce
Closes L-260927-a12b10
🤖 Generated with Claude Code
Summary by cubic
POST /v1/executenow carries the request id onto a run dispatched to a worker, so worker-written lines no longer lose it.The
/executeroute passes the id it resolved into the run'sRunMetadata, matching/start, so a Temporal worker's lines carry therequest_idthe response echoes.Pins
pipelexto==0.68.0, whoseexecuteaccepts the id.Breaking: a runtime line's trace context now appears as
pipelex.trace_idandpipelex.span_idinstead oftrace_id/span_id, andPOST /v1/codegenstampsengine_version0.68.0, socodegen.lockfiles committed against0.67.0need regenerating.Breaking: a deployment using the
gcplog sink now refuses to boot when Google rejects its credentials, where it used to boot and silently lose records.Docs now explain which worker lines carry the id and which do not (e.g.
POST /v1/validatedispatched to a worker still lacks it).Written for commit f48f899. Summary will update on new commits.