Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EMB-3907 tracer provider package with android implementation #36

Draft
wants to merge 1 commit into
base: jpmunz/EMBR-3907-add-trace-provider-export-package-setup
Choose a base branch
from

Conversation

jpmunz
Copy link
Contributor

@jpmunz jpmunz commented Jun 17, 2024

Adding a react-native-tracer-provider package. This provides a wrapper on the TracerProvider interface exposed by the (android) native SDK that also conforms to the TracerProvider interface on the JS side so that any JS otel instrumentation library should be able to use the Embrace SDK to write traces.

Keeping in draft for now as there is a number of TODOs/blockers atm:

  • Need to implement the iOS side of the native module, this is waiting on pointing to the latest 6.x version of the iOS Embrace SDK
  • Need to point to an updated version of the Android Embrace SDK that exposes the TracerProvider interface, this is under development at the moment, in the meantime I used the OTEL Java SDK for testing
  • During development I wrote the code and tests directly inside the 'basic-test-app', ran into a number of issues when I split this out into its own package, namely around being able to run the Kotlin tests on the native side, will need to figure out the proper setup and also make sure the package.json for this is consistent with how we've setup the other ones
  • Some TODOs on the JS implementation:
    • pass down schemaURL to the native side correctly
    • don't add a dependency on @opentelemetry/sdk-trace-web for the context manager

@jpmunz jpmunz requested a review from a team June 17, 2024 18:43
Copy link

@jpmunz jpmunz mentioned this pull request Jun 17, 2024
Copy link

codecov bot commented Jun 17, 2024

Codecov Report

Attention: Patch coverage is 94.18605% with 10 lines in your changes missing coverage. Please review.

Project coverage is 80.11%. Comparing base (e15ec11) to head (24583da).

Additional details and impacted files

Impacted file tree graph

@@                                     Coverage Diff                                      @@
##           jpmunz/EMBR-3907-add-trace-provider-export-package-setup      #36      +/-   ##
============================================================================================
+ Coverage                                                     77.40%   80.11%   +2.70%     
============================================================================================
  Files                                                            23       29       +6     
  Lines                                                           894     1066     +172     
  Branches                                                        169      211      +42     
============================================================================================
+ Hits                                                            692      854     +162     
- Misses                                                          202      210       +8     
- Partials                                                          0        2       +2     
Files Coverage Δ
...tracer-provider/src/EmbraceNativeTracerProvider.ts 100.00% <100.00%> (ø)
packages/react-native-tracer-provider/src/index.ts 100.00% <100.00%> (ø)
packages/react-native-tracer-provider/src/util.ts 95.65% <95.65%> (ø)
...ct-native-tracer-provider/src/EmbraceNativeSpan.ts 97.67% <97.67%> (ø)
...native-tracer-provider/src/TracerProviderModule.ts 57.14% <57.14%> (ø)
...-native-tracer-provider/src/EmbraceNativeTracer.ts 88.88% <88.88%> (ø)

... and 1 file with indirect coverage changes


// Add some span events
span2.addEvent("test-2-event-1");
span2.addEvent("test-2-event-2", 1700001002000);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these constant values have specific meanings?

const span1 = tracer.startSpan("test-1");
const span2 = tracer.startSpan("test-2", { kind: SpanKind.CLIENT });
const span3 = tracer.startSpan("test-3");
// Not ended so shouldn't be part of the output

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates an implicit dependency where generateTestSpans needs to be called before generateNestedSpans right?

describe("Tracer Provider", () => {
const expectValidIDs = (span: EmbraceSpanData) => {
expect(span.span_id).toHaveLength(16);
expect(span.span_id).not.toEqual("0000000000000000");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an expected format for span_id and trace_id we could check for?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see. Is there any reason we can't reuse the code from expectValidIDs or am I misunderstanding?

parent_span_id: "0000000000000000",
name: "test-1-updated",
start_time_unix_nano: 1718045981827000 * 1000000,
end_time_unix_nano: 1718045981827000 * 1000000 + 2591701,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the constant added values on lines 40, 51, and 80?

@@ -2,16 +2,41 @@
// add more properties as they become relevant for test specs, see:
// https://github.com/embrace-io/embrace-android-sdk/tree/master/embrace-android-sdk/src/main/java/io/embrace/android/embracesdk/payload

interface SessionPayload {
interface Session {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Payload was renamed to Message in other places. Is this correct?

/**
* EmbraceNativeSpan implements a Span over the native Embrace Android and iOS SDKs.
*
* A handful of simple attributes are maintained on the JS side for each span include a unique ID based on the

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this should be including instead of include

}

public addLink(link: Link): this {
return this.addLinks([link]);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we save an allocation on boxing the link in an array by inverting addLinks and addLink? That is, by writing this such that addLinks calls addLink rather than this way around?

return this.recording;
}

public recordException(exception: Exception, time?: TimeInput): void {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one doesn't return this like some of the ones above it?

Tracer,
} from "@opentelemetry/api";

export function generateTestSpans(tracer: Tracer) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Random thought: is it possible to construct a span where the end-time is before the start-time?

return time;
}

if (time instanceof Date) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are type checking semantics on 19 and 15 different?

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.

None yet

2 participants