Skip to content

feat(orchestrator): Telemetry - Trace running execution processing time - #334

Merged
morgan-wowk merged 1 commit into
masterfrom
tangle-inv-26772-orchestrator-processing-span
Aug 17, 2026
Merged

feat(orchestrator): Telemetry - Trace running execution processing time#334
morgan-wowk merged 1 commit into
masterfrom
tangle-inv-26772-orchestrator-processing-span

Conversation

@morgan-wowk

@morgan-wowk morgan-wowk commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Wraps the per-running-execution processing call in internal_process_running_executions_queue in a tangle.orchestrator span (orchestrator.process_running_execution), attributed by container_execution.id.

Why

Investigation of inv-26772 (orchestrator intermittently stalling) showed that attributing a freeze to the execution that caused it currently requires hand-correlating the After processing running container execution (duration: …ms) log with the launcher logs to recover the namespace. This span makes that per-execution processing duration a first-class, queryable signal keyed by the execution id, so "which execution blocked the loop, and for how long" is a single query instead of manual log archaeology.

Complements the query-timing logs added in #331 by turning the per-execution processing duration into an attributed span.

Naming

Uses container_execution.id (not execution.id): the processing loop operates on a ContainerExecution, matching the contextual_logging key and the cloud-pipelines.net/orchestration/container_execution.id annotation. execution_tracing.py already uses execution.id for an ExecutionNode (a different entity), so this avoids overloading one key for two entities.

Impact

One span per running-execution processing pass; it becomes the parent for any child spans emitted during processing. No behavior change.

Copy link
Copy Markdown
Collaborator Author

@Ark-kun Ark-kun changed the title feat(orchestrator): trace per-execution processing time by container_execution.id feat(orchestrator): Telemetry - Trace running execution processing time Aug 17, 2026

morgan-wowk commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator Author

Merge activity

  • Aug 17, 11:06 PM UTC: A user started a stack merge that includes this pull request via Graphite.
  • Aug 17, 11:06 PM UTC: @morgan-wowk merged this pull request with Graphite.

@morgan-wowk
morgan-wowk merged commit 0e0943c into master Aug 17, 2026
5 of 7 checks passed
morgan-wowk added a commit that referenced this pull request Aug 17, 2026
…info retrieval time (#335)

Wraps the output-artifact `get_info()` resolution in the `SUCCEEDED` branch of `internal_process_one_running_execution` in a child span (`orchestrator.get_output_artifact_info`).

## Why
This `get_reader().get_info()` call walks and stats **every file** of each output artifact on the single orchestrator thread. For a large Directory artifact (the inv-26772 trigger: ~88k per-merchant files) this is the confirmed freeze hot path — it runs for 40+ minutes and blocks all other executions. The span isolates that hot path within the parent processing span so its duration is directly measurable.

Timing-only, by design: per review, artifact **byte size** does not predict the stall (multi-gig artifacts resolve fast); **file count** is the meaningful dimension but is not available cheaply at this point, so no attribute is attached rather than a misleading one.

## Impact
One child span per succeeded execution's output resolution, nested under `orchestrator.process_running_execution` from [#334](#334). No behavior change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants