chore(deps): update deps matching "@opentelemetry/" #2408

pichlermarc · 2024-08-28T15:47:44Z

0.52.1 -> 0.53.0 @opentelemetry/api-logs (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/instrumentation (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/instrumentation-fetch (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/instrumentation-grpc (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/instrumentation-http (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/instrumentation-xml-http-request (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/propagator-aws-xray-lambda (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/sdk-logs (range-bump)
0.52.1 -> 0.53.0 @opentelemetry/sdk-node (range-bump)
1.25.1 -> 1.26.0 @opentelemetry/context-async-hooks
1.25.1 -> 1.26.0 @opentelemetry/context-zone
1.25.1 -> 1.26.0 @opentelemetry/context-zone-peer-dep
1.25.1 -> 1.26.0 @opentelemetry/core
1.25.1 -> 1.26.0 @opentelemetry/exporter-jaeger
1.25.1 -> 1.26.0 @opentelemetry/propagator-aws-xray
1.25.1 -> 1.26.0 @opentelemetry/propagator-b3
1.25.1 -> 1.26.0 @opentelemetry/propagator-jaeger
1.25.1 -> 1.26.0 @opentelemetry/resources
1.25.1 -> 1.26.0 @opentelemetry/sdk-metrics
1.25.1 -> 1.26.0 @opentelemetry/sdk-trace-base
1.25.1 -> 1.26.0 @opentelemetry/sdk-trace-node
1.25.1 -> 1.26.0 @opentelemetry/sdk-trace-web
1.25.1 -> 1.27.0 @opentelemetry/semantic-conventions

BEGIN_COMMIT_OVERRIDE
feat: update deps matching "@opentelemetry/"
END_COMMIT_OVERRIDE

codecov · 2024-08-28T15:58:50Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.64%. Comparing base (dfb2dff) to head (bd2a449).
Report is 224 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2408      +/-   ##
==========================================
- Coverage   90.97%   90.64%   -0.34%     
==========================================
  Files         146      156      +10     
  Lines        7492     7612     +120     
  Branches     1502     1571      +69     
==========================================
+ Hits         6816     6900      +84     
- Misses        676      712      +36

Files with missing lines	Coverage Δ
...etry-instrumentation-bunyan/src/instrumentation.ts	`97.84% <100.00%> (-0.86%)`	⬇️

... and 75 files with indirect coverage changes

pichlermarc · 2024-08-28T16:37:18Z

plugins/node/opentelemetry-instrumentation-bunyan/src/instrumentation.ts

@@ -96,7 +96,7 @@ export class BunyanInstrumentation extends InstrumentationBase<BunyanInstrumenta
  }

  override setConfig(config: BunyanInstrumentationConfig = {}) {
-    this._config = { ...DEFAULT_CONFIG, ...config };


reviewer note: this did override the enabled config and actually disabled the instrumentation, this went unnoticed until the change from open-telemetry/opentelemetry-js@0ee398d which now uses this method instead of setting it directly.

maryliag

you mention on the description the update on @opentelemetry/semantic-conventions, but I don't see the updates on this dependency

pichlermarc · 2024-08-29T07:35:43Z

you mention on the description the update on @opentelemetry/semantic-conventions, but I don't see the updates on this dependency

I think we exclusively caret depend on @opentelemetry/semantic-conventions package, so all updates are limited to package-lock.json 🙂

…correct span kind

…n, use correct span kind

pichlermarc · 2024-08-29T09:11:08Z

packages/opentelemetry-test-utils/src/test-fixtures.ts

+export enum OtlpSpanKind {
+  UNSPECIFIED = 0,
+  INTERNAL = 1,
+  SERVER = 2,
+  CLIENT = 3,
+  PRODUCER = 4,
+  CONSUMER = 5,
+}
+


reviewer note: some tests incorrectly used SpanKind instead of the OTLP representation of the same enum. The number values are different, but the tests that used it did look somewhat plausible.

INTERNAL spans were asserted to be SERVER spans, the first SERVER span was asserted as a CLIENT span as they shared the same value.

I opted to add this here as we'll change the exports from @opentelemetry/otlp-transformer soon-ish and that type we have there will not be exported anymore. Not using the type from there will help save use some work when we have to clean up the tests in this repo eventually.

pichlermarc · 2024-08-29T09:16:20Z

plugins/node/opentelemetry-instrumentation-express/test/express.test.ts

+        assert.strictEqual(spans[0].name, 'GET');
+        assert.strictEqual(spans[0].kind, testUtils.OtlpSpanKind.CLIENT);


reviewer note: with open-telemetry/opentelemetry-js#4866 http/https client instrumentation was fixed and now produces a client span.

Oh wow, this makes so much more sense. Thanks for fixing this!

Thanks for chasing this down, Marc!

Sorry for the confusion.
FWIW, the testUtils.runTestFixture() stuff was based on a similar thing we have at work on a separate repo. In that case the equivalent of the TestCollector class normalizes the span objects somewhat. One of those normalizations is to translate the OTLP span.kind and span.status values to their enum strings. So, test asserts are doing assertEqual(span.kind, 'SPAN_KIND_CLIENT') and assertEqual(span.status.code, 'STATUS_CODE_ERROR').

Again, FWIW, here is the normalization code I mean: https://github.com/elastic/elastic-otel-node/blob/main/packages/mockotlpserver/lib/normalize.js#L114-L154
I'm not proposing we use this in this repo.
I'd vaguely recall seeing something about a canonical JSON representation of OTLP service requests or of OTel signals. Given that, I think that would be a good target for normalization, and then tests could assert against that normalized form.

#2421 to get one more occurrence of SpanKind.* usage in this test file.

pichlermarc · 2024-08-29T09:20:12Z

plugins/node/opentelemetry-instrumentation-express/test/express.test.ts

+        assert.strictEqual(spans[0].name, 'GET');
+        assert.strictEqual(spans[0].kind, testUtils.OtlpSpanKind.CLIENT);
+        assert.strictEqual(spans[1].name, 'GET /post/:id');
+        assert.strictEqual(spans[1].kind, testUtils.OtlpSpanKind.SERVER);


reviewer note: this was previously asserted to be a client span, which it actually was not. Since the SDK-internal representation for a client span is 2 (SpanKind.CLIENT) and the OTLP represenation for a server span is 2 (OtlpSpanKind.SERVER), the test passed anyway.

It now asserts on the correct kind.

pichlermarc · 2024-08-29T09:21:09Z

plugins/node/opentelemetry-instrumentation-express/test/express.test.ts

+        assert.strictEqual(spans[2].kind, testUtils.OtlpSpanKind.INTERNAL);
+        assert.strictEqual(spans[2].parentSpanId, spans[1].spanId);
+        assert.strictEqual(spans[3].name, 'middleware - expressInit');
+        assert.strictEqual(spans[3].kind, testUtils.OtlpSpanKind.INTERNAL);


reviewer note: the same thing I described above also happened with SpanKind.SERVER and OtlpSpanKind.INTERNAL. I also adapted all following tests.

…ttp client span

pichlermarc · 2024-08-29T10:47:20Z

plugins/node/opentelemetry-instrumentation-koa/test/koa.test.ts

+        assert.strictEqual(spans[0].name, 'GET');
+        assert.strictEqual(spans[0].kind, testUtils.OtlpSpanKind.CLIENT);
+        assert.strictEqual(spans[1].name, 'GET /post/:id');
+        assert.strictEqual(spans[1].kind, testUtils.OtlpSpanKind.SERVER);
+        assert.strictEqual(spans[2].name, 'middleware - simpleMiddleware');
+        assert.strictEqual(spans[2].kind, testUtils.OtlpSpanKind.INTERNAL);
        assert.strictEqual(spans[2].parentSpanId, spans[1].spanId);
+        assert.strictEqual(spans[3].name, 'router - /post/:id');
+        assert.strictEqual(spans[3].kind, testUtils.OtlpSpanKind.INTERNAL);
+        assert.strictEqual(spans[3].parentSpanId, spans[2].spanId);


reviewer note: the same thing as in the express instrumentation is happening here as well, SpanKind SDK vs. OTLP-representation and an additional span that is inserted at positon 0.

JamieDanielson

This is great, thank you for fixing up the confusion with span kind and sorry for causing some of that headache with the tests! @robbkidd and I were just looking at that earlier today thinking something was off there.... This makes much more sense now.

JamieDanielson · 2024-08-29T20:23:57Z

plugins/node/opentelemetry-instrumentation-express/test/express.test.ts

+        assert.strictEqual(spans[0].name, 'GET');
+        assert.strictEqual(spans[0].kind, testUtils.OtlpSpanKind.CLIENT);


Oh wow, this makes so much more sense. Thanks for fixing this!

pichlermarc · 2024-08-30T10:55:04Z

This is great, thank you for fixing up the confusion with span kind and sorry for causing some of that headache with the tests! @robbkidd and I were just looking at that earlier today thinking something was off there.... This makes much more sense now.

No worries. 🙂 I also remember looking at them at some point but I did not think too much of it - they looked plausible enough for me not to second guess it before they were failing. 😬 Fortunately it was an easy fix 🙂

…also fix test flakiness This is a follow-up on open-telemetry#2408 (comment) to update one more usage of `SpanKind.*` to `testUtils.OtlpSpanKind.*`. While testing this locally I also noticed that the instr-express tests using runTestFixture are flaky. The issue is that `TestCollector#sortedSpans` can get the span ordering wrong when spans start in the same millisecond (the resolution of span.startTimeUnixNano). This happens with Express middleware spans on a fast machine. I've updated `sortedSpans` to fallback to using span.parentSpanId to attempt to get more reliable sorting.

…also fix test flakiness (#2421) This is a follow-up on #2408 (comment) to update one more usage of SpanKind.* to testUtils.OtlpSpanKind.*. While testing this locally I also noticed that the instr-express tests using runTestFixture are flaky. The issue is that TestCollector#sortedSpans can get the span ordering wrong when spans start in the same millisecond (the resolution of span.startTimeUnixNano). This happens with Express middleware spans on a fast machine. I've updated sortedSpans to fallback to using span.parentSpanId to attempt to get more reliable sorting.

chore(deps): update deps matching "@opentelemetry/"

1b9b495

pichlermarc added the dependencies Pull requests that update a dependency file label Aug 28, 2024

pichlermarc requested a review from a team August 28, 2024 15:47

github-actions bot added pkg:instrumentation-ioredis pkg:instrumentation-graphql pkg:instrumentation-mysql pkg:instrumentation-mysql2 pkg:instrumentation-fs pkg:instrumentation-restify pkg:instrumentation-dns labels Aug 28, 2024

github-actions bot assigned blumamir Aug 28, 2024

github-actions bot added pkg:resource-detector-alibaba-cloud pkg:resource-detector-aws pkg:resource-detector-gcp pkg:resource-detector-instana pkg:auto-instrumentations-node labels Aug 28, 2024

github-actions bot assigned david-luna Aug 28, 2024

github-actions bot added pkg:auto-instrumentations-web pkg:propagation-utils pkg:instrumentation-amqplib pkg:instrumentation-lru-memoizer labels Aug 28, 2024

github-actions bot assigned dyladan Aug 28, 2024

github-actions bot added pkg:instrumentation-mongoose pkg:instrumentation-tedious pkg:instrumentation-aws-lambda pkg:instrumentation-aws-sdk labels Aug 28, 2024

github-actions bot assigned haddasbronfman Aug 28, 2024

github-actions bot added pkg:instrumentation-bunyan pkg:instrumentation-cassandra-driver pkg:instrumentation-connect labels Aug 28, 2024

github-actions bot added pkg:sampler-aws-xray pkg:resource-detector-container pkg:resource-detector-azure pkg:test-utils labels Aug 28, 2024

github-actions bot assigned maryliag Aug 28, 2024

github-actions bot added pkg:instrumentation-runtime-node pkg:instrumentation-undici pkg-status:unmaintained This package is unmaintained. Only bugfixes may be acceped until a new owner has been found. pkg:auto-configuration-propagators labels Aug 28, 2024

maryliag approved these changes Aug 28, 2024

View reviewed changes

pichlermarc added 2 commits August 28, 2024 18:29

fixup! chore(deps): update deps matching "@opentelemetry/"

f8cb2e7

fixup! chore(deps): update deps matching "@opentelemetry/"

b408671

pichlermarc commented Aug 28, 2024

View reviewed changes

maryliag reviewed Aug 28, 2024

View reviewed changes

pichlermarc added 2 commits August 29, 2024 10:58

test(express): fix up tests to match fixed http instrumentation, use …

594b939

…correct span kind

fixup! test(express): fix up tests to match fixed http instrumentatio…

3c598bb

…n, use correct span kind

pichlermarc commented Aug 29, 2024

View reviewed changes

test(instrumentation-koa): assert for correct SpanKind, account for h…

bd2a449

…ttp client span

pichlermarc commented Aug 29, 2024

View reviewed changes

JamieDanielson approved these changes Aug 29, 2024

View reviewed changes

JamieDanielson mentioned this pull request Aug 29, 2024

feat(instrumentation-express): Use router path in router span names #2319

Merged

pichlermarc merged commit 9fa058e into open-telemetry:main Aug 30, 2024
22 checks passed

pichlermarc mentioned this pull request Aug 30, 2024

chore(deps): update deps @opentelemetry/semantic-conventions to 1.27 #2409

Merged

trentm mentioned this pull request Sep 4, 2024

test(instrumentation-express): update to use correct span kind enum; also fix test flakiness #2421

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps): update deps matching "@opentelemetry/" #2408

chore(deps): update deps matching "@opentelemetry/" #2408

pichlermarc commented Aug 28, 2024 •

edited

Loading

codecov bot commented Aug 28, 2024 •

edited

Loading

pichlermarc Aug 28, 2024 •

edited

Loading

maryliag left a comment

pichlermarc commented Aug 29, 2024

pichlermarc Aug 29, 2024

pichlermarc Aug 29, 2024

JamieDanielson Aug 29, 2024

trentm Sep 4, 2024

trentm Sep 4, 2024

trentm Sep 4, 2024

pichlermarc Aug 29, 2024

pichlermarc Aug 29, 2024

pichlermarc Aug 29, 2024

JamieDanielson left a comment

JamieDanielson Aug 29, 2024

pichlermarc commented Aug 30, 2024 •

edited

Loading

		assert.strictEqual(spans[0].name, 'GET');
		assert.strictEqual(spans[0].kind, testUtils.OtlpSpanKind.CLIENT);

chore(deps): update deps matching "@opentelemetry/" #2408

chore(deps): update deps matching "@opentelemetry/" #2408

Conversation

pichlermarc commented Aug 28, 2024 • edited Loading

codecov bot commented Aug 28, 2024 • edited Loading

Codecov Report

pichlermarc Aug 28, 2024 • edited Loading

Choose a reason for hiding this comment

maryliag left a comment

Choose a reason for hiding this comment

pichlermarc commented Aug 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JamieDanielson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pichlermarc commented Aug 30, 2024 • edited Loading

pichlermarc commented Aug 28, 2024 •

edited

Loading

codecov bot commented Aug 28, 2024 •

edited

Loading

pichlermarc Aug 28, 2024 •

edited

Loading

pichlermarc commented Aug 30, 2024 •

edited

Loading