This issue is more about the general design principle on all Sentry SDKs instead of just sentry-ruby. I want to discuss the necessity of falling back to Sentry.get_current_hub when the hub is not provided.

In sentry-python, it's done in Transaction.finish:

https://github.com/getsentry/sentry-python/blob/19fa43fec5a20b3561a16970ce395c93ac1be57d/sentry_sdk/tracing.py#L409-L417

In sentry-javascript, it looks to be done in the constructor?

https://github.com/getsentry/sentry-javascript/blob/fbdc8753ab5e54fb8c83101de78a805ec7335522/packages/tracing/src/transaction.ts#L22-L46

And currently, sentry-ruby does it like this

def initialize(name: nil, parent_sampled: nil, hub: Sentry.get_current_hub, **options)

Shouldn't we make the hub argument a hard requirement when initializing a Transaction object? Which means, we should never need to fallback to the current active hub.

I think we'd agree that a Transaction object should never be initialized manually by the user, which is also stated in sentry-javascript's comment:

   * This constructor should never be called manually. Those instrumenting tracing should use
   * `Sentry.startTransaction()`, and internal methods should use `hub.startTransaction()`.

If that's the case, hub.startTransaction() should always be able to provide a hub to the transaction, and thus never need to fallback to getCurrentHub().

So what I'm proposing are:

1. Stop making the hub argument optional for the Transaction constructor.
2. Remove all the fallback logic from the constructor or Transaction.finish. Because it must present and must be a Hub instance.

Wdyt?