opencensus-beam / opencensus_absinthe Goto Github PK

Resolution.path/1 will give us a list like ["post", 5, "author"]. Strikes me we could flatten that into a string like post[].author and put it to "absinthe.path".

The blueprint resolution span name is always "Blueprint". Perhaps that should be their schema module name, or something else. I'd appreciate feedback.

Complexity, for example. Anyone interested?

Many of the points in issue #15 apply here as well.

At the moment, [Dataloader][dataloader]s are a popular way to batch up Absinthe resolvers. This naturally hides a lot of the traceability by foregoing the default absinthe pipeline.

Perhaps a Dataloader that is a simple layer over the default dataloader that can either simply be used instead of the default or that provides simple functions to integrate with existing dataloaders.

Picked up while setting up CI: the default_pipeline/2 advertised in the documentation was renamed to traced_pipeline/2 during extraction. I didn't pick it up during post-extraction testing because I use a custom pipeline.

Workaround: use a custom pipeline traced_pipeline.

If there's a way to know whether the resolution turned out well, or not, we should perhaps tell :ocp_span.set_status/3 about it.

  testing:
    jobs:
      - test:
          name: "Elixir 1.8"
          elixir_version: "1.7"

Oops.

We've got the dependency and the CI machinery, but something's not working.

See also: rrrene/inch_ex#75.

Opencensus.Absinthe.Logger.set_logger_metadata/1 is a clone of code in opencensus_phoenix/instrumenter.ex and opencensus/plug/trace.ex, with an extra match for :undefined so it can clear the metadata when there's no span.

See also, opencensus-beam/opencensus_elixir#14.

I'm getting my root span from Opencensus.Plug.Trace and Opencensus.Absinthe.Middleware, but not the span from Opencensus.Absinthe.Phase.Pop.

Rhyming with opencensus-beam/opencensus_datadog#8 but on the input side, I'm shoving some attributes into spans that don't comply with the specification.

The existing push/pop phases will fail completely if you attempt to integrate them into a DocumentResolver pipeline. It'd be great if a simple way was provided to add similar tracing phases for such situations.

I hope to submit a PR shortly, but my absinthe knowledge is fairly limited, so feedback and discussion on this issue in the meantime would be invaluable. I also may say a number of things that are completely incorrect, so please bear with me!

For example, the existing tracer push/pop phases happen after the Absinthe.Phase.Blueprint and Absinthe.Phase.Document.Result phases. I assume the latter one will remain the same, but is there an analog to Absinthe.Phase.Blueprint when dealing with a DocumentResolver? If so, it shouldn't be overly difficult to add two new push/pop modules (or at least just push) and add an add_document_resolver_phases/1 function that does something similar.

Once that's done, all that needs to be added is a note in the readme that users' DocumentResolver modules should indeed override the pipeline/1 callback and include this new phase-adding function.

Please share any thoughts you might have! Perhaps this entire issue is misguided and I'm missing something obvious, which would actually be wonderful.

Thanks!

In preparation for absinthe-graphql/absinthe#663: provide an easy means to hook up via :telemetry rather than Absinthe.Pipeline without the user having to write their own code to call [:telemetry.attach_many/4].

I need a configurable callback I can use to set the seq_trace label per path at the beginning of its resolution. It'll be brittle, but I've little other hope of tying outbound spans to the fields rather than the whole blueprint.

The reference paths put into the span attributes are fully qualified. I'd like to trim them so they start with the closest lib or src to the end.