You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
shutdownTimeout is silently ignored on iOS (key/unit mismatch with cocoa shutdownTimeInterval) #6748
The documented shutdownTimeout option is honored on Android but has no effect on iOS. The native cocoa SDK always uses its default 2s shutdown flush interval regardless of what the user sets.
Root cause
The JS layer forwards options to native by key name (wrapper.ts → RNSentry.initNativeSdk(filteredOptions)), and shutdownTimeout passes through unchanged. On native:
Android — RNSentryStart.java maps shutdownTimeout → setShutdownTimeoutMillis(...). ✅ Works (both are milliseconds).
iOS — cocoa's dictionary parser (SentryOptionsInternal) only reads the key shutdownTimeInterval (an NSTimeInterval, i.e. seconds). It has no shutdownTimeout key, and RNSentryStart.m does no explicit handling. So the value is dropped and the native default (2s) is always used.
Unit: RN's shutdownTimeout is milliseconds (per its JSDoc and Android's ...Millis); cocoa's shutdownTimeInterval is seconds. A rename alone would be a 1000× error — the value must be divided by 1000.
Evidence
packages/core/src/js/options.ts — shutdownTimeout?: number documented as "milliseconds … default 2 seconds".
packages/core/src/js/wrapper.ts — shutdownTimeout is not filtered out, so it's forwarded verbatim.
packages/core/ios/RNSentryStart.m — no shutdown* handling.
cocoa SentryOptionsInternal — parses only shutdownTimeInterval (seconds).
In RNSentryStart.m (createOptionsWithDictionary), read shutdownTimeout (ms) and set sentryOptions.shutdownTimeInterval = value / 1000.0. Add test coverage on both platforms.
Environment
Affects all RN SDK versions on the current native binding; verified against bundled cocoa 9.29.0.
Activity
linear-code commentedon Sep 17, 2026
RN-787
github-actions commentedon Sep 24, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #6749, which was included in the 8.28.0 release.