import: prefer resource service.name over scope name in stdouttrace parser#147
Merged
Conversation
The stdouttrace parser took the service name from the instrumentation scope name, falling back to the synth.service attribute only when the scope name was empty. Current binaries emit a constant module-path scope name on every span, so importing motel's own --stdout output collapsed all spans into a single service named after the Go module path, and the resulting topology failed validation. Parse the Resource attributes and use resource service.name first, then the synth.service attribute, then the scope name, matching the OTLP path's precedence. The SDK's unknown_service placeholder is ignored in both paths so older outputs (placeholder resource, per-service scope names) still import correctly. Adds a round-trip regression test that imports the output of a fresh run --stdout instead of the checked-in fixture. Fixes #146 https://claude.ai/code/session_01L9tNd23CewbWJ8hMTGheyf
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
2 participants
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.
Fixes #146
The stdouttrace parser took the service name from
InstrumentationScope.Name, falling back to thesynth.serviceattribute only when the scope name was empty. Current binaries emit a constant module-path scope name (github.com/andrewh/motel) on every span, so importing motel's own--stdoutoutput collapsed all spans into a single service named after the Go module path, and the resulting topology failed validation.Changes
Resourceattributes, and the service name precedence is: resourceservice.name, then thesynth.serviceattribute, then the instrumentation scope name — matching the OTLP path.unknown_serviceplaceholder is treated as absent in both the stdouttrace and OTLP paths, so output from older binaries (placeholder resourceservice.name, per-service scope names) still imports correctly. The checked-in fixtures continue to pass for this reason, now via thesynth.servicefallback rather than the scope name.serviceNameKey/synthServiceKeyconstants in place of repeated string literals.Tests
synth.service).TestRunStdoutImportRoundTrip) that runsrun --stdoutand feeds the fresh output throughimportandvalidate, rather than relying on the checked-in fixture that masked this regression. It also asserts the inferred topology does not contain the module path as a service name.Verified the exact repro from the issue with the built binary:
run --stdout→import→validatenow produces a valid topology with the original service names.https://claude.ai/code/session_01L9tNd23CewbWJ8hMTGheyf
Generated by Claude Code