Both findings addressed in 3ce928c:

1. Post-init isolation sync (medium): Configuration#isolation_level= now applies the level to HubStorage when the SDK is already initialized, so a post-init change to Sentry.configuration.isolation_level actually takes effect instead of leaving the SDK on the old backend. The initialize default is assigned to the ivar directly so a throwaway Configuration.new can't clobber the active isolation level (only Sentry.init builds the live config).

2. Fiber specs vs Ruby < 3.2 fallback (high): the :fiber-asserting specs now stub fiber_storage_available? so they're deterministic across the Ruby matrix, plus an explicit downgrade-to-:thread spec. They previously asserted :fiber unconditionally and would have failed on the < 3.2 cells, where :fiber correctly falls back to :thread. Added a regression test for the post-init sync too.

thanks a lot @SeanLF, if you don't mind, I will reduce the code a bit and make it more minimal.

Hello! I ran into this PR because I was having an issue in an app I'm running with Falcon that was leaking Sentry tags across requests where it should have been impossible. I ran this all through Claude Fable, so please accept my apologies, I'll try to keep the AI slop to a minimum, but I think we might have room to improve. I think the tl;dr is a bit strange because of my currently-mixed workload where I'm running Falcon for web, but SolidQueue for jobs, and SolidQueue doesn't ship with an Async/Fiber mode yet (but hopefully will soon: rails/solid_queue#728)

So... Claude slop follows, edited a bit to keep it short, I hope this is helpful, but please accept my apologies for not entirely working through this myself in detail -- this should be taken with a grain of salt, but I thought it worth sharing:

A caveat worth considering before this ships: Fiber storage is inherited by Thread.new, sharing one hub across threads.

While evaluating the :fiber approach (we prototyped equivalent Fiber-storage hub accessors on 6.6.2 while waiting for the release), we hit a caveat worth raising before hub_isolation_level ships: Ruby's fiber storage is inherited by Thread.new, not just Fiber.new, and the inherited values are the same objects — so a hub stored via Fiber[] in one fiber is shared (not copied) into any thread that fiber spawns.

Why this bites in practice

In a typical Rails app, hubs get seeded early and implicitly — e.g. Sentry::Rails::Breadcrumb::ActiveSupportLogger calls Sentry.add_breadcrumb → get_current_hub on every ActiveSupport notification, so the first SQL query in a process seeds the current fiber's hub. Any thread pool created after that point (a job processor's workers, an app's own worker threads) inherits that one hub into every thread. In :fiber mode:

• Concurrent jobs in a threaded processor (we reproduced the shape with a Solid Queue-style pool) all read and write one shared scope: 4 workers → 1 hub, each seeing another job's tags from inside its own Sentry.with_scope.
• The shared Hub#@stack Array is then pushed/popped from multiple OS threads without synchronization.

So a mixed web+jobs app that enables :fiber globally (the natural reading of a config option) trades cross-request contamination on the web side for cross-job contamination on the worker side.

Repro sketch (Ruby 3.4, semantics-level)

Fiber[:hub] = Object.new
threads = Array.new(4) { Thread.new { Fiber[:hub] } }
threads.map(&:value).map(&:object_id).uniq.size # => 1 — all threads share the fiber's object

With hub accessors reading Fiber[KEY] || clone, the || clone fallback never fires in those threads — they inherit a non-nil hub — so the per-context isolation the fallback was designed to provide is silently bypassed.

Possible mitigation

Tagging the stored hub with its owning thread restores per-thread cloning at thread boundaries while keeping fiber inheritance within a thread:

def get_current_hub
  thread, hub = Fiber[KEY]
  thread.equal?(Thread.current) ? hub : clone_hub_to_current_thread
end

def clone_hub_to_current_thread
  hub = get_main_hub.clone
  Fiber[KEY] = [Thread.current, hub]
  hub
end

@trevorturk thanks for digging into this! My own claude managed to reproduce it on master

Fiber.new inherits storage the same way Thread.new does, so :fiber never fixed the Falcon case it was built for either. The shared @stack is also pushed and popped from several threads with no synchronization.

The existing regression spec missed it because it calls Sentry.clone_hub_to_current_thread inside each fiber, which overwrites the inherited entry. Real request fibers never call that.

Two notes on your mitigation. Tagging with Thread.current fixes the worker-thread case but leaves sibling fibers sharing one hub, since they run on the same thread; tagging with the owning fiber covers both. And clone_hub_to_current_thread returns whatever the setter returns, so Fiber[k] = [thread, hub] hands callers the Array.

Cloning the hub is also not enough on its own. Hub#clone deep-dups the scope's span, which builds a fresh SpanRecorder, so child-fiber spans land on a detached transaction copy and are never sent. The fork has to keep the live span.

PR incoming. This is unreleased, so it can land before the next release

Excellent! Thank you for digging into that. Please link the PR here so we can keep track and I'll QA IRL when everything is settled.

PR is up: #3036

It tags each stored entry with its owning fiber, so a context that inherited one takes its own copy. The copy keeps the live span, otherwise child spans land on a detached transaction copy and are never sent.

One thing that turned up while testing across the matrix, relevant to your Solid Queue setup: the fiber-storage gem polyfills Fiber[] on Ruby < 3.2 and on JRuby, so :fiber is live there too. That polyfill inherits into child fibers but not into Thread.new, so on those Rubies only the sibling-fiber half of the bug exists; worker threads already start from the main hub. On 3.2+ with native fiber storage you get both halves, which matches what you saw.

Happy to have it QA'd IRL once it lands.