memoizing across Fibers? (heavy graphql-ruby usage)

[jakswa]

I'm struggling to find out whether Flipper should be able to memoize during the usage of Fibers within a single thread. We just happen to use graphql-ruby heavily, and it relies on fibers:

GraphQL::Dataloader uses Ruby’s Fiber, a lightweight concurrency primitive which supports application-level scheduling within a Thread. By using Fiber, GraphQL::Dataloader can pause GraphQL execution when data is requested, then resume execution after the data is fetched.

I notice Flipper relies on Thread.current[:flipper_instance] which you can see does not persist across Fiber boundaries:

> Flipper.instance.__id__
=> 418860
> Fiber.new { puts Flipper.instance.__id__ }.resume
470320
> Fiber.new { puts Flipper.instance.__id__ }.resume
475280
> Flipper.instance.__id__
=> 418860

I understand if catering to Fiber usage is outside the scope of Flipper's goals, but wanted to open a discussion for my (and others') future reference.

[jakswa]

I'm not sure I gave enough detail to highlight why the default rails memoization is broken in Fibers. The flipper rack middleware sets memoize to true, and loses this state when a graphql fiber runs. This shows what I mean:

# this is in the rack middleware, wrapping the request
> Flipper.memoize = true
=> true
> Flipper.memoizing?
=> true

# graphql kicks off execution, and simulating being in a fiber trying to do *any* memoization
> Fiber.new { Flipper.memoizing? }.resume
=> false

[jakswa]

Ah, here is what I was missing: graphql-ruby has implemented a bridge across this gap, and copies Thread locals to Fibers upon creation:

    def spawn_fiber
      fiber_vars = get_fiber_variables
      Fiber.new(blocking: !@nonblocking) {
        set_fiber_variables(fiber_vars)

taken from https://github.com/rmosolgo/graphql-ruby/blob/5dcdb597c4dd9dc943b8a86f11c271a32d2a97a4/lib/graphql/dataloader.rb#L65-L77