feat(telemetry): add registry adapter to aggregate execute span

[yordis]

• When using :global registry, the registry adapter introduces per-call distributed lookup latency that is otherwise invisible in traces — surfacing the adapter on every execute span makes it possible to filter and compare latency by registry type in observability tooling

[cursor]

PR Summary

Low Risk
Low risk: adds a new telemetry/OpenTelemetry attribute and metadata field without changing command execution behavior, but may affect downstream telemetry consumers that pattern-match on aggregate execute metadata.

Overview
Adds the configured process registry_adapter to aggregate execute telemetry metadata and propagates it into the OpenTelemetry execute span as a new commanded.registry.adapter attribute.

Updates Commanded.OpenTelemetry.CommandedAttributes to define the new attribute key and adjusts factories/tests to include and assert this attribute across aggregate execute start/stop/error scenarios.

^{Reviewed by Cursor Bugbot for commit 2ca8906. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Warning

Rate limit exceeded

@yordis has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 8 minutes and 2 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 8 minutes and 2 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7d88db0c-510f-4b0c-b741-cbd1b9f47f90

📥 Commits

Reviewing files that changed from the base of the PR and between 4b29b2d and 2ca8906.

📒 Files selected for processing (5)

• lib/commanded/aggregates/aggregate.ex
• lib/commanded/opentelemetry/aggregate.ex
• lib/commanded/opentelemetry/commanded_attributes.ex
• test/opentelemetry/aggregate_test.exs
• test/support/factory.ex

Walkthrough

Aggregate telemetry now includes the configured registry adapter in its metadata; the OpenTelemetry instrumentation exposes that value as a new span attribute used during aggregate execute spans. Tests and factory helpers were updated to provide the new metadata field.

Changes

Cohort / File(s)	Summary
Telemetry metadata enrichment lib/commanded/aggregates/aggregate.ex	Fetches registry_adapter from application config and adds it to the aggregate telemetry metadata under :registry_adapter.
OpenTelemetry instrumentation lib/commanded/opentelemetry/aggregate.ex	Adds commanded_registry_adapter attribute to the aggregate execute-start span, sourcing value from telemetry metadata.
OTel attribute definitions lib/commanded/opentelemetry/commanded_attributes.ex	Introduces new attribute function commanded_registry_adapter/0 returning the attribute key :"commanded.registry.adapter".
Tests & test factories test/opentelemetry/aggregate_test.exs, test/support/factory.ex	Tests updated to expect the new "commanded.registry.adapter" span attribute; factory now returns :registry_adapter in aggregate execute metadata (defaults to Commanded.Registration.LocalRegistry).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• feat: implement OpenTelemetry instrumentation for aggregates #45 — Similar changes to OpenTelemetry aggregate instrumentation and test factory to add/use a :registry_adapter field.

Poem

🐰 I hopped through traces, soft and fleet,
Added my name to each telemetry beat,
Registry adapter tucked in the span,
Hooray for traces across the land! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely describes the main change: adding registry adapter metadata to the aggregate execute span for telemetry observability.
Description check	✅ Passed	The description is directly related to the changeset, explaining the motivation for adding registry adapter information to telemetry spans.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch yordis/feat-registry-adapter-attribute

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/commanded/aggregates/aggregate.ex`:
- Around line 772-782: The docs for the "execute" telemetry event metadata are
out of sync with runtime: add the registry_adapter field to the documented
metadata contract so it matches the emitted payload (the runtime map includes
registry_adapter from Commanded.Application.registry_adapter). Update the
execute telemetry metadata definitions (the doc/typedoc or `@doc` block in
aggregate.ex that lists metadata keys for the execute event) to include
registry_adapter and describe its value/type consistently with the other fields.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 17ac352d-aa7b-4404-b731-5640e5383d05

📥 Commits

Reviewing files that changed from the base of the PR and between 0b024c1 and 15a1805.

📒 Files selected for processing (3)

• lib/commanded/aggregates/aggregate.ex
• lib/commanded/opentelemetry/aggregate.ex
• lib/commanded/opentelemetry/commanded_attributes.ex

[coderabbitai]

🧹 Nitpick comments (1)

test/opentelemetry/aggregate_test.exs (1)

116-116: Add one non-default adapter test case to prevent hardcoded-value regressions.

Right now all new assertions validate only Commanded.Registration.LocalRegistry. A single case using a different adapter value would prove this is propagated from metadata/config, not constantized.

Example test addition

+    test "propagates non-default registry adapter into span attributes" do
+      aggregate_uuid = UUID.uuid4()
+      causation_id = UUID.uuid4()
+      correlation_id = UUID.uuid4()
+
+      meta =
+        Factory.build_aggregate_execute_metadata(
+          aggregate_uuid: aggregate_uuid,
+          causation_id: causation_id,
+          correlation_id: correlation_id,
+          registry_adapter: Commanded.Registration.GlobalRegistry
+        )
+
+      :telemetry.span([:commanded, :aggregate, :execute], meta, fn ->
+        {:ok, meta}
+      end)
+
+      assert_receive {:span, span(attributes: attributes)}, 1000
+      attrs = :otel_attributes.map(attributes)
+      assert attrs[:"commanded.registry.adapter"] == "Commanded.Registration.GlobalRegistry"
+    end

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/opentelemetry/aggregate_test.exs` at line 116, Add a test in
aggregate_test.exs that uses a non-default adapter value for the
"commanded.registry.adapter" metadata key (e.g., "Some.Custom.Adapter") to
ensure the adapter value is propagated from metadata/config and not hardcoded;
create/setup the event or request with that metadata value, run the same
aggregation/assertion logic used in the existing tests, and assert the
aggregated result contains the non-default "commanded.registry.adapter" string
rather than only accepting "Commanded.Registration.LocalRegistry".

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@test/opentelemetry/aggregate_test.exs`:
- Line 116: Add a test in aggregate_test.exs that uses a non-default adapter
value for the "commanded.registry.adapter" metadata key (e.g.,
"Some.Custom.Adapter") to ensure the adapter value is propagated from
metadata/config and not hardcoded; create/setup the event or request with that
metadata value, run the same aggregation/assertion logic used in the existing
tests, and assert the aggregated result contains the non-default
"commanded.registry.adapter" string rather than only accepting
"Commanded.Registration.LocalRegistry".

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 66b1bca2-58e8-4a86-8972-9ff03a05ed05

📥 Commits

Reviewing files that changed from the base of the PR and between 15a1805 and 4b29b2d.

📒 Files selected for processing (2)

• test/opentelemetry/aggregate_test.exs
• test/support/factory.ex