Prefer Fiber#storage over copying thread locals

[ioquatix]

I believe this code is extremely risky.

graphql-ruby/lib/graphql/dataloader.rb

Line 80 in 8a21eb1

Thread.current.keys.each do |fiber_var_key|

[rmosolgo]

Hey, thanks for taking a look and sharing your concerns. The goal here is to retain compatibility with code that uses Thread.current.

I just started using Fiber[...] for library internals in #5034, and I'm open to migrating GraphQL-Ruby's usage to Fiber storage instead.

I'm also open to making this Thread.current behavior opt-in somehow (instead of default). But could you help me understand the risk you see with it now?

[ioquatix]

Risks:

1. Context Misalignment: Thread-local variables are tied to a thread's specific operations, and copying them can lead to incorrect behavior in the new thread's context.

2. Shared Mutable State Risks: Copying mutable thread-local variables can introduce race conditions and data corruption.

3. Resource Mismanagement: Thread-local variables managing resources like database connections or file handles may be improperly shared or closed.

4. Framework/Library Assumptions: Frameworks relying on Thread.current for logs, tracing, or error propagation may break or produce incorrect results.