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
Hey @mydea,
I did some research and exploration on both sentry-javascript & @effect/opentelemetry in the meantime and developed a proposal for how this integration can be approached.
Summary:
The goal is to provide a seamless integration between Sentry and @effect/opentelemetry by introducing an effectIntegration helper. This will remove the need for manual setup, unify tracing and error reporting, and make it easier for developers using Effect to leverage Sentry’s capabilities out of the box.
Steps :
We can start by creating a dedicated effectIntegration helper inside @sentry/opentelemetry, so users don’t need to manually add span processors, propagators, or configure tracing.
We can reuse the existing TracerProvider from @effect/opentelemetry instead of duplicating setup, ensuring that all Effect spans automatically flow into Sentry.
We can then extend this integration to capture unhandled Effect.Cause errors and send them to Sentry, bridging structured error handling with Sentry’s event system.
Next, we can align distributed tracing by integrating SentryPropagator and SentrySampler with Effect’s OTEL setup, keeping trace context consistent across services.
These are the approximate steps I see for this integration.
If this proposal aligns with you, I’d love to take this on — feel free to assign it to me. 🙏
Looking into this some more, I think we actually need to do something different.
It seems that @effect/opentelemetry actually sets up an otel tracer etc. We do not want this!
Instead, what we need to do (I think) is vendor in (?) the stuff we need to do to tap into effects tracer, with our own, instead.
The end experience should be: Users do nothing, or possible add some sentry layer, and stuff is captured, no more config needed.
@mydea Okay..understood
so..effect is supposed to be a integrated part in the sdk workflow rather than a optional feature.
if we don't want to rely on @effect/opentelemetry's tracer setup, the better approach is to hook into Effect’s tracing layer directly. Instead of building on top of their OTEL provider, we can vendor in the minimal parts needed (span lifecycle hooks, context propagation) and connect them to Sentry’s SentrySpanProcessor.
Revised Path:
We can create a lightweight effectIntegration that attaches to Effect’s runtime and starts emitting Sentry spans without requiring OTEL initialization.
We can intercept or wrap Effect's internal tracer to automatically forward spans to Sentry (similar to how @sentry/opentelemetry plugs into OTEL).
We can still capture unhandled Effect.Cause errors and map them into Sentry events for error reporting.
The user-facing experience remains: “Initialize Sentry + add a simple Sentry layer, and everything just works.”
@mydea Okay..understood so..effect is supposed to be a integrated part in the sdk workflow rather than a optional feature.
if we don't want to rely on @effect/opentelemetry's tracer setup, the better approach is to hook into Effect’s tracing layer directly. Instead of building on top of their OTEL provider, we can vendor in the minimal parts needed (span lifecycle hooks, context propagation) and connect them to Sentry’s SentrySpanProcessor.
Revised Path:
We can create a lightweight effectIntegration that attaches to Effect’s runtime and starts emitting Sentry spans without requiring OTEL initialization.
We can intercept or wrap Effect's internal tracer to automatically forward spans to Sentry (similar to how @sentry/opentelemetry plugs into OTEL).
We can still capture unhandled Effect.Cause errors and map them into Sentry events for error reporting.
The user-facing experience remains: “Initialize Sentry + add a simple Sentry layer, and everything just works.”
looking forward for your pov.
yeah, that sounds about right! 👍 we're happy about contributions, feel free to ask if you need pointers/help!
Hey @Divyanshu7001 thanks a lot! We already saw the PR. Quick heads-up: We're having an internal hackathon ("Hackweek") this week, so we'll likely only look at it next week.
Activity
linear commentedon Jul 23, 2025
JS-763 Add `effectIntegration` to Node SDK
Divyanshu7001 commentedon Jul 23, 2025
Hey @mydea,
I did some research and exploration on both sentry-javascript & @effect/opentelemetry in the meantime and developed a proposal for how this integration can be approached.
Summary:
The goal is to provide a seamless integration between Sentry and @effect/opentelemetry by introducing an effectIntegration helper. This will remove the need for manual setup, unify tracing and error reporting, and make it easier for developers using Effect to leverage Sentry’s capabilities out of the box.
Steps :
These are the approximate steps I see for this integration.
If this proposal aligns with you, I’d love to take this on — feel free to assign it to me. 🙏
mydea commentedon Jul 23, 2025
Looking into this some more, I think we actually need to do something different.
It seems that
@effect/opentelemetryactually sets up an otel tracer etc. We do not want this!Instead, what we need to do (I think) is vendor in (?) the stuff we need to do to tap into effects tracer, with our own, instead.
The end experience should be: Users do nothing, or possible add some sentry layer, and stuff is captured, no more config needed.
Divyanshu7001 commentedon Jul 23, 2025
@mydea Okay..understood
so..effect is supposed to be a integrated part in the sdk workflow rather than a optional feature.
if we don't want to rely on @effect/opentelemetry's tracer setup, the better approach is to hook into Effect’s tracing layer directly. Instead of building on top of their OTEL provider, we can vendor in the minimal parts needed (span lifecycle hooks, context propagation) and connect them to Sentry’s SentrySpanProcessor.
Revised Path:
The user-facing experience remains: “Initialize Sentry + add a simple Sentry layer, and everything just works.”
looking forward for your pov.
Divyanshu7001 commentedon Jul 24, 2025
hello @mydea sir ,
sorry to disturb again...if you could give a follow up pov , that would be great :)
mydea commentedon Jul 24, 2025
yeah, that sounds about right! 👍 we're happy about contributions, feel free to ask if you need pointers/help!
17 remaining items
Lms24 commentedon Aug 20, 2025
Hey @Divyanshu7001 thanks a lot! We already saw the PR. Quick heads-up: We're having an internal hackathon ("Hackweek") this week, so we'll likely only look at it next week.
Divyanshu7001 commentedon Sep 7, 2025
@marbemac @Lms24 @mydea
Hello guys, hoping to get a follow up on this if possible.😅
RulaKhaled commentedon Sep 8, 2025
Sorry for the delay here @Divyanshu7001, I will ping the team and review this asap
JPeer264 commentedon Mar 5, 2026
We decided to now move along with an
effectIntegrationfor now. Instead we go and create a new@sentry/effectSDK. More info here: #19641JPeer264 commentedon Mar 18, 2026
As an update to everyone who subscribed to this. We recently released the new
@sentry/effectSDK as an alpha release: https://www.npmjs.com/package/@sentry/effectmarbemac commentedon Mar 18, 2026
❤️ hell yeah! can't wait to give it a go