Skip to content

feat: support attributes on span links#227

Merged
andrewh merged 2 commits into
mainfrom
claude/cool-wright-53f462
Jun 24, 2026
Merged

feat: support attributes on span links#227
andrewh merged 2 commits into
mainfrom
claude/cool-wright-53f462

Conversation

@andrewh

@andrewh andrewh commented Jun 23, 2026

Copy link
Copy Markdown
Owner

Summary

Closes #215

  • Added LinkConfig struct with custom YAML unmarshaling so links accept both bare-string (- producer.enqueue) and structured form (- ref: producer.enqueue \n attributes: ...)
  • Plumbed attributes through the full stack: LinkConfigOperationConfigLink (topology) → LinkRef (plan) → trace.Link.Attributes in both engine.go (walkTrace) and emit.go (realtime mode)
  • Updated docs/examples/span-links.yaml to show the structured form with attributes
  • Added TestParseLinkConfig (YAML round-trip for both forms) and TestEngineSpanLinkAttributes (attributes appear on emitted spans)

Test plan

  • go test ./pkg/synth/... — all existing tests pass, new tests cover both DSL forms and attribute propagation
  • Verify bare-string links still work unchanged (existing tests cover this)
  • Check docs/examples/span-links.yaml parses and emits correctly with link attributes

🤖 Generated with Claude Code

https://claude.ai/code/session_01FBAoX4p3qC5NnVg9fGhRiR


Generated by Claude Code

claude and others added 2 commits June 23, 2026 19:23
Extend the link DSL to accept an optional attributes map alongside the
existing bare-string ref form.  Attributes are plumbed through LinkConfig →
OperationConfig → Link (topology) → LinkRef (plan) → trace.Link.Attributes
so they appear on every emitted OTel span link.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FBAoX4p3qC5NnVg9fGhRiR
Span link attributes were stored as map[string]string, which made the new
structured link form inconsistent with the rest of the topology DSL and
flattened numeric or boolean values before they reached trace.Link.

Reuse AttributeValueConfig and resolved Attributes for links so validation,
deterministic key ordering, and typed attribute generation follow the
existing operation, event, metric, and log path. Apply the same generated
attribute.KeyValue values in walkTrace and realtime SpanPlan emission.

Update the span links example to use the established attribute value syntax
and cover typed link attributes in config, topology, plan, emit, and engine
tests.
@andrewh

andrewh commented Jun 24, 2026

Copy link
Copy Markdown
Owner Author

Adversarial review finding and patch pushed.

  1. Blocker found: the first version modeled LinkConfig.Attributes as map[string]string. That made the new structured link form diverge from the existing topology attribute grammar (AttributeValueConfig) and flattened values before trace.Link, so link attributes such as a batch index could not preserve an OTel numeric type. That undercut the batch and fan-in use case described in the linked issue.

Patch pushed to this branch:

  • cadb745 changes link config attributes to map[string]AttributeValueConfig, resolves them to sorted Attributes, and emits generated typed attribute.KeyValue values in both walkTrace and realtime plan/emit.
  • Updated docs/examples/span-links.yaml to use the established value: attribute syntax.
  • Added coverage for parsing and validation, topology resolution, planned emission, realtime emitTrace, and walkTrace.

Validation run:

  • go test -count=1 ./pkg/synth
  • go test -count=1 ./pkg/synth/...
  • make test
  • make lint
  • make build
  • build/motel validate docs/examples/span-links.yaml
  • build/motel run --stdout --duration 1s docs/examples/span-links.yaml produced consumer links with messaging.batch.message.index as INT64 plus the string link attributes present.

Remaining note: I did not treat semconv-aware validation as a blocker in this patch because motel does not currently warn on ordinary span attributes through that path; adding link-only semconv behavior would be inconsistent and should be a separate policy decision if we want it.

@andrewh
andrewh merged commit 0f03ed0 into main Jun 24, 2026
2 checks passed
@andrewh
andrewh deleted the claude/cool-wright-53f462 branch June 24, 2026 20:55
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.

Support attributes on span links

2 participants