Cleanup configuration interface and make it fail gracefully

[crespire]

Issue Description

On server startup, when Sentry configuration may not be fully initialized, it seems that there are spots where Sentry.configuration may be nil.

This is very similar to other previous issues I've encountered around Sentry.configuration initialization: #2782 #2386

We should generally guard against non-initialized Sentry.configuration calls by ensuring that Sentry is initialized.

Currently, the method just exits early https://github.com/getsentry/sentry-ruby/blob/e219832b57c5aa32e41be4462dbe421c8c58bc67/sentry-ruby/lib/sentry-ruby.rb#L164C1-L167C8

Could it be changed such that if we are not initialized, we actually initialize Sentry? I feel this would prevent a whole class of NoMethod no nil errors I've personally run into.

Reproduction Steps

During app boot (after a new deploy for example), we occasionally run into this type of error.

Expected Behavior

Sentry does not cause a 500.

Actual Behavior

Sentry causes a 500 with no backtrace.

Ruby Version

3.4.4

SDK Version

6.1.1

Integration and Its Version

Rails 8.0.2

Sentry Config

Default

[linear]

RUBY-120

[sl0thentr0py]

I agree that this issue has gotten out of hand but to fix this is not so trivial and requires some core refactoring.

Could it be changed such that if we are not initialized, we actually initialize Sentry?

No, we cannot do that because that's not how the SDK design is supposed to be, that would defeat the purpose of having an initialize at all. But we could have a fallback configuration always, just that it could potentially cause weird behavior if not done properly.

Sentry is supposed to be initialized extremely early in your app startup process, could you try moving it (prefixing the initializer with 01_, for instance) so that it runs first?

Alternatively, can you tell me which particular check fails in your case so I can fix it?

[crespire]

I can try to manipulate the loading order, let me see and I'll report back.