apollo-tracing-elixir icon indicating copy to clipboard operation
apollo-tracing-elixir copied to clipboard

Support Absinthe Subscription Tests

Open athal7 opened this issue 7 years ago • 2 comments

Absinthe 1.4 added support for GraphQL subscriptions, as well as a support module for testing them. This module primes absinthe to load eagerly by running the schema with the default pipeline, so that subscription tests with a short timeout can pass. Unfortunately this does not allow apollo_tracing to add its metadata, so the middleware fails to successfully pattern match when called (https://github.com/sikanhe/apollo-tracing-elixir/blob/master/lib/apollo_tracing/middleware.ex#L10)

cc @benwilson512

athal7 avatar Dec 14 '17 16:12 athal7

There may be a few things going on here. One thing that shipped in 1.4 that will help this library is the ability to configure the pipeline from within the schema module itself. This is extremely useful for libraries like this one, where you want certain phases to be added no matter where or how you run the schema. You can do this by adding these lines to the schema:

def pipeline(phases) do
  phases
  |> ApolloTracing.Pipeline.add_phases()
end

Now it is unnecessary to do the pipeline: option in Plug. This also means that using Absinthe.run is safe again, since this callback is always run. In theory this should solve the issue with the prime function, but it seems like there are still issues.

benwilson512 avatar Dec 14 '17 16:12 benwilson512

Update on this now that https://github.com/sikanhe/apollo-tracing-elixir/pull/10 has been merged.

Problem 1: The biggest thing standing in the way of working subscriptions is support for batched resolution. Absinthe batch-resolves all subscriptions for an event, which is handy because it gives you really excellent datastore access. The problem is, this is accomplished by threading the acc through ALL documents. Right now, this library is storing resolution info in the acc after each field completes, which means tracing from all documents ends up in the result. Notably this would also happen for ordinary queries if done via transport batching.

Problem 2: The second major issue is that the use of pipeline phases right now doesn't gel super well with how subscriptions work. When a subscription document comes in, it runs ALL phases right up until resolution. In the case of this library then, the root execution info sets a start time based on when the document is prepared, not when it's actually run.

This would be solved by switching this library over to acting as a plugin instead of using phases to initialize the tracing datastructures, and I have a branch in progress with these changes. I'll tackle Problem #1 after this is accomplished.

Absinthe also has a bit of buggy behaviour when it comes to handling pipelines returned by plugins that do more than simply resolve again. I do plan on fixing this in absinthe, but there are some challenges there. I think I can work around it easily enough in this package, but if you see some odd bits that'll be why. I'll call it out in each PR.

benwilson512 avatar Dec 16 '17 21:12 benwilson512