danielmschmidt / apollo-opentracing Goto Github PK

Due to this line. Is it not possible to have race conditions where a resolver may receive the wrong span?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• fix: Update dependency @types/node to v14.18.63
• fix: Update dependency @types/supertest to v2.0.16
• fix: Update dependency @commitlint/travis-cli to v17.8.1
• fix: Update dependency all-contributors-cli to v6.26.1
• fix: Update dependency semantic-release to v20.1.3
• fix: Update actions/checkout action to v4
• fix: Update actions/setup-node action to v4
• fix: Update dependency @types/node to v20
• fix: Update dependency typescript to v5
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix: Replace Apollo GraphQL packages with @apollo/server >=3.0.0
• fix: Replace dependency apollo-server-plugin-base with @apollo/server ^4.0.0
• fix: Replace dependency apollo-server-types with @apollo/server ^4.0.0
• fix: Update dependency ts-jest to v27.1.5
• fix: Update commitlint monorepo to v19 (major) (@commitlint/config-conventional, @commitlint/travis-cli)
• fix: Update dependency graphql to v16
• fix: Update dependency graphql-tools to v9
• fix: Update dependency semantic-release to v23
• fix: Update dependency supertest to v6 (supertest, @types/supertest)
• fix: Update jest monorepo to v29 (major) (@types/jest, jest, ts-jest)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

With the implementation added in #83 we have this problem introduced as a shortcut to get a better version out sooner.

The underlying problem is given this query

{
  query: {
	list: {
  		value      
    }
  } 
}

and given that list is an array of three we would have these span relationships:

• list => value times three as we call it for each of the array elements

The goal would be to have something like this:

• list => [0] => value
• list => [1] => value
• list => [2] => value

That way we would have a clear separation which item took longest, which might be interesting as they might be of different types.

Implementation

To implement this we would need to start a new span once we enter such an array and finish it once we close on the array. We would most likely need to work a lot with the info argument, specifically the selectionSet.

I created simple app based on apollo tutorial:
https://github.com/mwieczorek/nodejs-tracing

Even if I provide zipkin headers (x-b3-traceid - see sample curl command in above repo) I don't see parent span or traceId extracted from those headers.
When debug the code I see that on
https://github.com/DanielMSchmidt/apollo-opentracing/blob/master/src/index.ts#L116
headers are like:

infos.request.headers
Headers {Symbol(map): Object}
[[StableObjectId]]:7
Symbol(map):Object {host: Array(1), user-agent: Array(1), accept: Array(1), …}
__proto__:Headers {get: , forEach: , set: , …}

And in this loop: https://github.com/jaegertracing/jaeger-client-node/blob/master/src/propagators/zipkin_b3_text_map_codec.js#L100

it iterates over get, forEach, set.
Because of that doesn't get to any zipkin headers.

Hi,

The new apollo version will favor the new plugin api and extensions will be deprecated.

[deprecated] A "OpentracingExtension" was defined within the "extensions" configuration for Apollo Server. The API on which this extension is built ("graphql-extensions") is being deprecated in the next major version of Apollo Server in favor of the new plugin API. See https://go.apollo.dev/s/plugins for the documentation on how these plugins are to be defined and used.

Are there any plans to migrate the this project to use the new extensions api?

Thank you,
Dorin

For example when a field can't be mapped to the GraphQL type

{"level":50,"time":1625050489069,"pid":32066,"hostname":"foo","name":"GraphQLError","code":"GRAPHQL_ERR","message":"Cannot return null for non-nullable field Teaser.id."...

This error is only logged by didEncounterErrors. Finding the right span is very fuzzy and attaching an error=true tag has no result.

https://www.apollographql.com/docs/apollo-server/integrations/plugins/#request-lifecycle-event-flow

We are using Jaeger.

Hi,

I've been playing around with this for a bit, and I'm really liking it. Is there a way to name the top level spans something other than request? It would be far more useful for me if it were something like {mutation|query}: {name}.

Is this achievable? How might I go about configuring this?

Thank you!

Would it be possible to trace a specific mutation? We would like to see whether the users are actively using a specific mutation or query calls to track their usage and time. Would that information once sent to tracing tools like zipkin, is there a way to pull that information?

H There, is there a way not to log the results as these will contain PII (Personally identifiable Information), which we're not allowed to log?

Thanks in advance.

When implementing my own context, is it expected to extend SpanContext?

I ask because when importing SpanContext it is found in the subdirectory 'apollo-opentracing/dist/context' rather than the index file. Reaching into subdirectories is often seen as an anti-pattern because the subdirs are considered internal modules.

import { SpanContext } from 'apollo-opentracing/dist/context';
export interface MyResolverContext extends SpanContext {
  myCustomThing: CustomThing
}

When creating an instance of this extension, a client's context must be of type SpanContext.

const apolloServer = new ApolloServer({
    extensions: [(): OpenTracingExtension<MyResolverContext> => 
		new OpenTracingExtension({ server: tracer, local: tracer })]
});

The addContextHelpers function is also a useful implementation that clients should use that is in a nested dir. https://github.com/DanielMSchmidt/apollo-opentracing/blob/master/src/context.ts#L34-L50

Thanks for your time.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Hello,

Running apollo-opentracing@^1.2.0 with apollo-server@^2.4.6 I receive the following type error:

Type '(() => OpentracingExtension<any>)[]' is not assignable to type '(() => GraphQLExtension<any>)[]'.
  Type '() => OpentracingExtension<any>' is not assignable to type '() => GraphQLExtension<any>'.
    Type 'OpentracingExtension<any>' is not assignable to type 'GraphQLExtension<any>'.
      Types of property 'requestDidStart' are incompatible.
        Type '(infos: RequestStart) => (() => void) | undefined' is not assignable to type '(o: { request: Pick<Request, "url" | "method" | "headers">; queryString?: string | undefined; parsedQuery?: DocumentNode | undefined; operationName?: string | undefined; variables?: { ...; } | undefined; persistedQueryHit?: boolean | undefined; persistedQueryRegister?: boolean | undefined; context: any; requestConte...'.
          Types of parameters 'infos' and 'o' are incompatible.
            Type '{ request: Pick<Request, "url" | "method" | "headers">; queryString?: string | undefined; parsedQuery?: DocumentNode | undefined; operationName?: string | undefined; variables?: { ...; } | undefined; persistedQueryHit?: boolean | undefined; persistedQueryRegister?: boolean | undefined; context: any; requestContext: ...' is not assignable to type 'RequestStart'.
              Types of property 'request' are incompatible.
                Type 'Pick<Request, "url" | "method" | "headers">' is missing the following properties from type 'Request': clone, bodyUsed, arrayBuffer, json, text

Hi

I can't find any mention of subscriptiopns, are these supported by this library?

thanks for the great work!

Build a setup where tests are run against a configured version of apollo-server with a fake opentracing tracer to make sure that everything is started as it should be.

I want to get traceID from my client so it will be help full to get a trace log request ID, is it possible ?

Hi. May I know how does this work with Apollo Federation in place where the Apollo Gateway is going to send requests to multiple different microservices behind the scenes? In such cases, how do we configure this - At the gateway level or service level? Any sample implementations behind this?

Thanks in advance.

👋 thanks for this project! looks like we're still using apollo server v3 - making a tracking ticket to update to v4.

Providing this stack trace so it hopefully shows up for folks googling it:

Unexpected error processing request: TypeError: Cannot read property 'getSpanByPath' of undefined

  at internalExecuteOperation (node_modules/@apollo/server/src/ApolloServer.ts:1304:19)
  at runHttpQuery (node_modules/@apollo/server/src/runHttpQuery.ts:232:27)
  at runPotentiallyBatchedHttpQuery (node_modules/@apollo/server/src/httpBatching.ts:85:12)
  at ApolloServer.executeHTTPGraphQLRequest (node_modules/@apollo/server/src/ApolloServer.ts:1058:14)

(^ this is because apollo server renames s/context/contextValue/ https://www.apollographql.com/docs/apollo-server/migration/#fields-on-graphqlrequestcontext)

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Things like this should likely be a tag instead of a log.
The rule of thumb I use is that things known at the start of the span should all be tags.

• Add tags to snapshot serializer
• log/tag variables
• field resolver tags (fieldName, fieldType)

The graphql-go package has a good reference for tags

Hey guys!, this is my first time creating an issue. Sorry if this is not the right way.

Our teams is using the openTracing-plugin to trace on Apollo v2 on a previous repo, we are currently trying to use this on Apollo v3, but the apollo-server-plugin-base version used is not compatible with the used in Apollo v3.

Could you guys update it to use the new version? Changes seems to be mainly related to types.

Hi @DanielMSchmidt, I want to use apollo-opentracing with my graphql-yoga server, but I see that you are using another form of applying this middleware (app.use()). Does this module support graphql-yoga middlewares?

Using tracer (initTracer()) from: https://github.com/yurishkuro/opentracing-tutorial/tree/master/nodejs

Code (src/index.ts):

const OpentracingExtension = require('apollo-opentracing').default;

const serverTracer = initTracer('serverTracer');

const localTracer = initTracer('localTracer');

const server = new GraphQLServer({
    schema,
    context,
    middlewares: [
        () =>
            new OpentracingExtension({
                server: serverTracer,
                local: localTracer
            })
    ]
});

Output:

TypeError: String cannot represent value: { serverTracer: { _tags: [Object], _metrics: [Metrics], _serviceName: "serverTracer", _reporter: [CompositeReporter], _sampler: [ConstSampler], _logger: [Object], _baggageSetter: [BaggageSetter], _debugThrottler: [DefaultThrottler], _injectors: [Object], _extractors: [Object], _process: [Object], _traceId128bit: undefined, _shareRpcSpan: undefined }, localTracer: { _tags: [Object], _metrics: [Metrics], _serviceName: "localTracer", _reporter: [CompositeReporter], _sampler: [ConstSampler], _logger: [Object], _baggageSetter: [BaggageSetter], _debugThrottler: [DefaultThrottler], _injectors: [Object], _extractors: [Object], _process: [Object], _traceId128bit: undefined, _shareRpcSpan: undefined }, requestSpan: null, shouldTraceRequest:
[function alwaysTrue], shouldTraceFieldResolver: [function alwaysTrue], onFieldResolveFinish: undefined, onFieldResolve: undefined, onRequestResolve: [function emptyFunction] }

Any help is appreciated. Thanks!

It's currently a peer dependency, just for the typescript type. We could also just copy the type over.

Add new hooks for logging, plus make the existing logs hooks.
A hook needs to get as much information as possible to the current point of time and it needs to get access to both existing spans.

Why are there two tracers in the interface of this plugin? Why would I want to use a different tracer for the two different kinds of traces? What exactly are these two kinds? How is a "server" trace different from a "local" trace?

I understand I can just supply the same tracer for both, but that makes it even more confusing. If I can do that, why wouldn't I?

It would be great if this could be clarified. I'd be happy to submit a PR with a documentation upgrade afterwards 😄

Given this query

{
  myAlias: field
}

You currently get a span with the name "field", where it should be "myAlias"

On registry https://registry.npmjs.org, the "latest" version (v5.0.11) of dependency travis-deploy-once has the following deprecation notice:

We recommend to use Travis Build Stages instead

Marking the latest version of an npm package as deprecated results in the entire package being considered deprecated, so contact the package author you think this is a mistake.

Affected package file(s): package.json

If you don't care about this, you can close this issue and not be warned about travis-deploy-once's deprecation again. If you would like to completely disable all future deprecation warnings then add the following to your config:

"suppressNotifications": ["deprecationWarningIssues"]

See https://www.apollographql.com/docs/apollo-server/migration/#almost-all-plugin-events-are-now-async

Apollo v3 requires that all plugin events be async.

Hello @DanielMSchmidt , is it possible to prolongate opentracing headers to next requests in requestDidStart function like

    this.requestSpan = rootSpan;
    if(infos.requestContext != null && infos.requestContext.request != null && infos.requestContext.request.http != null) {
      this.serverTracer.inject(rootSpan, FORMAT_HTTP_HEADERS, infos.requestContext.request.http.headers);
    }
    return () => {

so any server that consume our HTTP can prolongate span

Hi Daniel! Is it your intention that other people be able to use this software? If so, would you consider adding a license to this repository?

Hey there,

I am getting a peerDepending error for graphql, I would like to use the package next to my implementation but doing a downgrade from graphql to 14.0.x is not an option.
Is there a problem in supporting 14.x.x versions?

graciously