[WIP] Nexus metrics backport (3/3): completion-path emission + impl=chasm + functional test#10788
Draft
tekkaya wants to merge 2 commits into
Draft
Conversation
Complete the HSM caller-side metrics backport by emitting from the async completion path (CompleteNexusOperation callbacks): CompletionHandler now records the terminal outcome (succeeded/failed/canceled) and, when it fabricates a started transition for a completion that arrives before the start response, the schedule-to-start latency. The shared emit helpers are refactored into package functions so both the executor and completion paths use them. The history Handler is given the nexusoperations Config (via fx) so it can resolve the metric tag config and pass it, along with its metrics handler, into CompletionHandler. Also adds the internal impl="chasm" tag to the CHASM caller metrics so the two engines are distinguishable during the HSM->CHASM migration (the HSM side emits impl="hsm"); this tag is intended to be stripped at the external-observability boundary. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds TestNexusOperationCallerMetrics, which runs an in-workflow Nexus
operation to completion and asserts the caller-side operation metric
(nexus_operation_success) is emitted with the caller namespace, endpoint,
real workflow type, and engine ("impl") tag, plus a latency metric.
The test is parameterized over the HSM and CHASM engines (via the existing
parallelsuite HSM/CHASM runners) and asserts the engine-specific impl tag
(hsm vs chasm), exercising both implementations at parity.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tekkaya
force-pushed
the
gokhan/nexus-op-caller-metrics-completion
branch
from
d39c00a to
ccb62d4
Compare
tekkaya
force-pushed
the
gokhan/nexus-op-caller-metrics-hsm
branch
from
59ee603 to
0db1af8
Compare
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
WIP / draft — for review, not ready to merge.
Stacked on #10787 (base branch
gokhan/nexus-op-caller-metrics-hsm). Review #10786 → #10787 → this PR in order.This PR (3/3)
Completes the backport.
CompleteNexusOperationcallbacks):CompletionHandlernow records the terminal outcome (succeeded/failed/canceled) and, when it fabricates a started transition for a completion that arrives before the start response, the schedule-to-start latency.Handleris given thenexusoperationsConfig via fx so it can resolve the metric tag config and pass it (with its metrics handler) intoCompletionHandler.impl="chasm"to the CHASM caller metrics so the two engines are distinguishable during the migration (HSM side emitsimpl="hsm").TestNexusOperationCallerMetrics: runs an in-workflow Nexus operation to completion and asserts the caller metric is emitted withnamespace,nexus_endpoint, the realworkflowType, and the engineimpltag. Parameterized over both HSM and CHASM engines (assertsimpl=hsmvsimpl=chasm) — verifies both implementations at parity.Chronicle/extobs ingestion is tracked in DEVPROD-1804. The internal
impltag is intended to be stripped at the external-observability boundary so the customer-facing rollup aggregates across engines.Stack
NodeBackendaccessorsimpl=chasm+ functional test🤖 Generated with Claude Code