Problem
retrieveParsedDsn() is called synchronously on the main thread during Sentry.init() → preInitConfigurations() at Sentry.java:600. This triggers lazy Dsn construction, which performs URI parsing, regex-based org ID extraction, and key validation — all blocking the main thread.
Despite loadLazyFields() being designed to run on a background thread (submitted via executor at Sentry.java:359), the DSN is already parsed by the time that background task runs, so the lazy loading optimization doesn't help here.
Call chain on main thread
SentryInitProvider.onCreate() (main thread, ContentProvider lifecycle)
- →
SentryAndroid.init()
- →
Sentry.init() → preInitConfigurations() (line 309)
- →
options.retrieveParsedDsn() (line 600) — triggers lazy Dsn parsing on main thread
- Later:
new SentryClient(options) → RequestDetailsResolver → options.retrieveParsedDsn() (line 35 of RequestDetailsResolver.java) — hits cached value, cheap
What Dsn constructor does
new URI(dsn) — Java's URI parsing (known to be slow)
- Regex matching for org ID extraction
- Public/secret key validation
- URI normalization
Possible approaches
- Defer DSN parsing: The DSN string validation in
preInitConfigurations could be simplified to a lightweight string check (non-empty, basic format), deferring full Dsn object construction to the background loadLazyFields() call
- Custom DSN parser: Replace
java.net.URI with a faster custom parser (already noted in the project description)
- Move
preInitConfigurations validation off main thread: Restructure init so validation happens after executor service is available
Files
sentry/src/main/java/io/sentry/Sentry.java — preInitConfigurations() at line 584
sentry/src/main/java/io/sentry/SentryOptions.java — retrieveParsedDsn() and loadLazyFields()
sentry/src/main/java/io/sentry/Dsn.java — constructor with URI parsing
sentry/src/main/java/io/sentry/RequestDetailsResolver.java — second call site (cached)
Problem
retrieveParsedDsn()is called synchronously on the main thread duringSentry.init()→preInitConfigurations()atSentry.java:600. This triggers lazyDsnconstruction, which performs URI parsing, regex-based org ID extraction, and key validation — all blocking the main thread.Despite
loadLazyFields()being designed to run on a background thread (submitted via executor atSentry.java:359), the DSN is already parsed by the time that background task runs, so the lazy loading optimization doesn't help here.Call chain on main thread
SentryInitProvider.onCreate()(main thread, ContentProvider lifecycle)SentryAndroid.init()Sentry.init()→preInitConfigurations()(line 309)options.retrieveParsedDsn()(line 600) — triggers lazy Dsn parsing on main threadnew SentryClient(options)→RequestDetailsResolver→options.retrieveParsedDsn()(line 35 of RequestDetailsResolver.java) — hits cached value, cheapWhat
Dsnconstructor doesnew URI(dsn)— Java's URI parsing (known to be slow)Possible approaches
preInitConfigurationscould be simplified to a lightweight string check (non-empty, basic format), deferring fullDsnobject construction to the backgroundloadLazyFields()calljava.net.URIwith a faster custom parser (already noted in the project description)preInitConfigurationsvalidation off main thread: Restructure init so validation happens after executor service is availableFiles
sentry/src/main/java/io/sentry/Sentry.java—preInitConfigurations()at line 584sentry/src/main/java/io/sentry/SentryOptions.java—retrieveParsedDsn()andloadLazyFields()sentry/src/main/java/io/sentry/Dsn.java— constructor with URI parsingsentry/src/main/java/io/sentry/RequestDetailsResolver.java— second call site (cached)