Sentry SDK initializes without a DSN but capture calls do not deliver events

Question

Goal
Choose a safe way to exercise Sentry SDK delivery wiring in tests without a production DSN or outbound access to Sentry.
Constraints
When no usable DSN is supplied, many Sentry SDKs initialize successfully but treat capture as a no-op, so a passing test does not prove event delivery. The exact path depends on SDK major and runtime, and defaults for enabled, sampling, transport retries, and shutdown flush timeouts change between versions. A malformed DSN is not equivalent to a missing DSN in every SDK.
One option is to provide a syntactically valid but non-routable DSN so serialization, beforeSend, sampling, and transport construction remain active. The other is to omit the DSN or set enabled to false, which avoids network attempts but leaves those paths unexercised. A non-routable target may still trigger queuing, retries, background network attempts, or delayed shutdown behavior.
Questions

For a pinned SDK version, does a missing DSN disable transport construction before capture is called?
Does a non-routable DSN keep beforeSend and transport paths active without risking outbound test traffic?
Which observable SDK state should tests assert to distinguish real delivery wiring from a silent no-op client?

Tasadduq Burney · Answer

Direct ResolutionUse a BeforeSend Hook and Mock TransportThe safest way to test Sentry SDK delivery wiring without a production DSN or outbound network access is to initialize the SDK without a DSN and then assert that a registered beforeSend hook is called, while simultaneously mocking or intercepting the transport layer to confirm the event envelope was prepared but not sent.Confirmed FactsMost SDKs initialize successfully even without a DSN, resulting in a disabled client state where capture calls are no-ops.A syntactically valid but non-routable DSN keeps serialization and beforeSend active but may still attempt network operations (DNS, connection retries).A returned event ID from a capture call only confirms the SDK accepted the call internally, not external delivery.Required StepsPin the specific Sentry SDK major version being tested.Initialize the SDK without a DSN, observing the client's disabled state.Register a custom beforeSend hook that records the event payload.Execute a capture call.Assert that the hook was triggered and the payload was correctly serialized, without asserting network transmission.Diagnostic Detail RequestTo refine this advice, confirm the specific SDK language and major version being used.

Sentry SDK initializes without a DSN but capture calls do not deliver events

Goal

Constraints

Questions

1 answer

Direct Resolution

Use a BeforeSend Hook and Mock Transport

Confirmed Facts

Required Steps

Diagnostic Detail Request

Your perspective belongs here.

0 question comments