Stop using fiber-local variables

[coding-chimp]

GraphQL added a fiber-based batch loading API in one of their recent releases. Since the GraphQL execution is happening inside fibers and skylight is using fiber-local variables in the instrumenter to keep track of the current trace, it's pretty much breaking tracing inside the GraphQL runtime.

To fix this I changed the usage of fiber-local variables to thread-local. We're currently using this in production and it looks good.

I've thrown together a little app that I used for testing. I will also provide a link to one of our endpoints in the in-app messenger. I've been already talking to @zvkemp about this there.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @coding-chimp on file. In order for us to review and merge your code, please sign the CLA.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @coding-chimp on file. In order for us to review and merge your code, please sign the CLA.

[zvkemp]

@coding-chimp The test failures were caused by an update to Rails, and have been fixed on the master branch. Can you rebase this branch when you have a chance?

We'll review this internally to validate that the thread-local variables still work as expected.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @coding-chimp on file. In order for us to review and merge your code, please sign the CLA.

[zvkemp]

Hi @coding-chimp, we'll continue to investigate this issue, but as of right now it does not appear that moving to thread-local variables will be a one-size-fits-all solution. It's somewhat difficult to survey the entire Ruby ecosystem for Fiber usage (most results on Github appear to be small experiments), but notably Falcon uses fibers for request concurrency, so Skylight would need to remain fiber-local in that context.

[coding-chimp]

Hey, @zvkemp, thanks for the update. I didn't really know about Falcon when I opened this PR. This certainly makes things more complicated.

Not sure if it's helpful, but there's now also an issue about this on the DataDog agent.

[zvkemp]

There's been some additional work done in GraphQL's Dataloader on this:

rmosolgo/graphql-ruby#3461

Putting this here for reference only; I'm not yet convinced that was this was necessarily a good idea.