fixing traces #3081

Merged

mfreeman451 merged 1 commit from refs/pull/3081/head into staging

2026-03-26 00:10:51 +00:00

mfreeman451 commented

2026-03-26 00:10:25 +00:00

(Migrated from github.com)

Owner

Imported from GitHub pull request.

Original GitHub pull request: #3082
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/3082
Original created: 2026-03-26T00:10:25Z
Original updated: 2026-03-26T00:17:19Z
Original head: carverauto/serviceradar:updates/traces-missing
Original base: staging
Original merged: 2026-03-26T00:10:51Z by @mfreeman451

IMPORTANT: Please sign the Developer Certificate of Origin

Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:

Signed-off-by: J. Doe <j.doe@domain.com>

Describe your changes

Issue ticket number and link

Code checklist before requesting a review

I have signed the DCO?
The build completes without errors?
All tests are passing when running make test?

Imported from GitHub pull request. Original GitHub pull request: #3082 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/pull/3082 Original created: 2026-03-26T00:10:25Z Original updated: 2026-03-26T00:17:19Z Original head: carverauto/serviceradar:updates/traces-missing Original base: staging Original merged: 2026-03-26T00:10:51Z by @mfreeman451 --- ## IMPORTANT: Please sign the Developer Certificate of Origin Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include a [DCO sign-off statement]( https://developercertificate.org/) indicating the DCO acceptance in one commit message. Here is an example DCO Signed-off-by line in a commit message: ``` Signed-off-by: J. Doe <j.doe@domain.com> ``` ## Describe your changes ## Issue ticket number and link ## Code checklist before requesting a review - [ ] I have signed the DCO? - [ ] The build completes without errors? - [ ] All tests are passing when running make test?

Copilot commented

2026-03-26 00:13:57 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR review comment.

Original author: @Copilot
Original URL: https://github.com/carverauto/serviceradar/pull/3082#discussion_r2991776487
Original created: 2026-03-26T00:13:57Z
Original path: go/pkg/consumers/db-event-writer/service.go
Original line: 418

consumerFilterSubjects expands both otel.traces and otel.traces.raw into two filter subjects. When using stream-based routing, configs now set the trace stream subject to otel.traces.raw (no otel.traces entry), so any message delivered on otel.traces will route to an empty table (Processor.getTableForSubject won’t match) and ProcessBatch will fail with an unsupported table error. Consider only expanding the legacy otel.traces value to include otel.traces.raw (but keep otel.traces.raw as-is), or alternatively update routing/config so both subjects map to the same table.

	case "otel.traces":
		// The collector publishes traces under `otel.traces.raw`.
		// Preserve legacy config compatibility while widening the JetStream
		// consumer filter so trace messages are actually delivered.
		return []string{"otel.traces", "otel.traces.raw"}
	case "otel.traces.raw":
		// When configured directly with the raw trace subject, do not expand
		// to include the legacy base subject. This avoids routing messages
		// under `otel.traces` to an unsupported table.
		return []string{"otel.traces.raw"}

Imported GitHub PR review comment. Original author: @Copilot Original URL: https://github.com/carverauto/serviceradar/pull/3082#discussion_r2991776487 Original created: 2026-03-26T00:13:57Z Original path: go/pkg/consumers/db-event-writer/service.go Original line: 418 --- `consumerFilterSubjects` expands both `otel.traces` and `otel.traces.raw` into two filter subjects. When using stream-based routing, configs now set the trace stream subject to `otel.traces.raw` (no `otel.traces` entry), so any message delivered on `otel.traces` will route to an empty table (`Processor.getTableForSubject` won’t match) and `ProcessBatch` will fail with an unsupported table error. Consider only expanding the legacy `otel.traces` value to include `otel.traces.raw` (but keep `otel.traces.raw` as-is), or alternatively update routing/config so both subjects map to the same table. ```suggestion case "otel.traces": // The collector publishes traces under `otel.traces.raw`. // Preserve legacy config compatibility while widening the JetStream // consumer filter so trace messages are actually delivered. return []string{"otel.traces", "otel.traces.raw"} case "otel.traces.raw": // When configured directly with the raw trace subject, do not expand // to include the legacy base subject. This avoids routing messages // under `otel.traces` to an unsupported table. return []string{"otel.traces.raw"} ```

Copilot commented

2026-03-26 00:13:57 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR review comment.

Original author: @Copilot
Original URL: https://github.com/carverauto/serviceradar/pull/3082#discussion_r2991776523
Original created: 2026-03-26T00:13:57Z
Original path: go/pkg/consumers/db-event-writer/service_test.go
Original line: 89

This test now expects svc.subjects() to include otel.traces even though the configured stream subject is only otel.traces.raw. With the current routing logic, subscribing to otel.traces without also having a stream mapping for it can cause trace messages on otel.traces to route to an empty table and fail processing. Once the trace subject expansion logic is adjusted, update this expected subject list accordingly.

		[]string{"logs.otel.processed", "otel.metrics", "otel.metrics.>", "otel.traces.raw"},

Imported GitHub PR review comment. Original author: @Copilot Original URL: https://github.com/carverauto/serviceradar/pull/3082#discussion_r2991776523 Original created: 2026-03-26T00:13:57Z Original path: go/pkg/consumers/db-event-writer/service_test.go Original line: 89 --- This test now expects `svc.subjects()` to include `otel.traces` even though the configured stream subject is only `otel.traces.raw`. With the current routing logic, subscribing to `otel.traces` without also having a stream mapping for it can cause trace messages on `otel.traces` to route to an empty table and fail processing. Once the trace subject expansion logic is adjusted, update this expected subject list accordingly. ```suggestion []string{"logs.otel.processed", "otel.metrics", "otel.metrics.>", "otel.traces.raw"}, ```