Uh oh!
There was an error while loading. Please reload this page.
feat(effect): Support v4 beta - #20394
Merged
Merged
Conversation
JPeer264
commented
Apr 20, 2026
| // Use bracket notation to avoid Webpack static analysis flagging missing exports | ||
| // This is important for Effect v3 compatibility. | ||
| const MetricModule = Metric; |
MemberAuthor
There was a problem hiding this comment.
This is a little hack I had to do in order to support Effect v3 in the browser. It seems that Webpack checks if snapshotUnsafe is available and fails if it doesn't. snapshotUnsafe is for Effect v4 and is not part of the package. By using MetricModule it is possible to work around this issue.
JPeer264force-pushed
the
jp/effect-v4-core
branch
from
April 20, 2026 07:00
0ddfb1b to
0f6b4deCompareJPeer264
marked this pull request as ready for review
April 20, 2026 07:09
Contributor
size-limit report 📦
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0f6b4de. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
s1gr1d
approved these changes
Apr 20, 2026
s1gr1d
left a comment
Member
There was a problem hiding this comment.
Looks good 👍
Just a general comment: when trying to differentiate the logic between v3 and v4 you always check for the structure of specific objects. If e.g. in v4 cause.reasons is always an array of Reason objects, you could theoretically just do something like isV4() and then apply the logic. But I am not sure if there is an easy way of finding out the used version (maybe checking the package.json)
JPeer264
commented
Apr 20, 2026
MemberAuthor
I thought for it to make it more generic, but since we do not have any bundler plugin or similar there is no chance to check for it. Effect itself doesn't have a versioning internally, which makes it harder. |
Comment on lines
+39
to
+43
| const V3_COUNTER_STATE_TYPE_ID = Symbol.for('effect/MetricState/Counter'); | ||
| const V3_GAUGE_STATE_TYPE_ID = Symbol.for('effect/MetricState/Gauge'); | ||
| const V3_HISTOGRAM_STATE_TYPE_ID = Symbol.for('effect/MetricState/Histogram'); | ||
| const V3_SUMMARY_STATE_TYPE_ID = Symbol.for('effect/MetricState/Summary'); | ||
| const V3_FREQUENCY_STATE_TYPE_ID = Symbol.for('effect/MetricState/Frequency'); |
Contributor
There was a problem hiding this comment.
Bug: The hardcoded symbols used for Effect v3 metric detection are untested. If they are incorrect, v3 metrics will be silently dropped.
Severity: HIGH
Suggested Fix
Add an E2E test case for the effect-node (v3) application that specifically sends and verifies metrics. This will validate that the hardcoded symbol keys are correct and that metrics are being reported as expected for Effect v3 users.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/effect/src/metrics.ts#L39-L43
Potential issue: The code uses hardcoded, globally-registered symbols (e.g.,
`Symbol.for('effect/MetricState/Counter')`) to detect Effect v3 metric types. This logic
is not covered by any unit or E2E tests, as the test suite only runs against Effect v4.
If these symbol keys do not exactly match the internal symbols used by Effect v3, the
`sendV3MetricToSentry` function will fail to identify any metrics, causing them to be
silently dropped without any errors or warnings.
Also affects:
packages/effect/src/metrics.ts:71~94
Did we get this right? 👍 / 👎 to inform future reviews.
Uh oh!
There was an error while loading. Please reload this page.
JPeer264 added a commit
that referenced
this pull request
Apr 21, 2026
This adds support to Effect v4, but also keeps the compatibility for v3.
There is no way that we can unit test against v3, as the
`devDependencies` need to use `effect@4` and an updated `@effect/vitest`
version, which is not compatible with Effect v3 (this is added in
The API for Effect v4 has changed a little, so there are safeguards to
detect if it is v3 or v4 and uses the correct API. The good part is that
for users nothing changed, so they still can use the same methods in
their app as before (ofc, respecting the new Effect v4 API).
Before (Effect v3):
```ts
const SentryLive = Layer.mergeAll(
Sentry.effectLayer({
dsn: '__DSN__',
tracesSampleRate: 1.0,
enableLogs: true,
}),
Layer.setTracer(Sentry.SentryEffectTracer),
Logger.replace(Logger.defaultLogger, Sentry.SentryEffectLogger),
Sentry.SentryEffectMetricsLayer,
);
```
After (Effect v4):
```js
const SentryLive = Layer.mergeAll(
Sentry.effectLayer({
dsn: '__DSN__',
tracesSampleRate: 1.0,
enableLogs: true,
}),
Layer.succeed(Tracer.Tracer, Sentry.SentryEffectTracer),
Logger.layer([Sentry.SentryEffectLogger]),
Sentry.SentryEffectMetricsLayer,
);
```
Both usages still work and are represented in the E2E tests.JPeer264 added a commit
that referenced
this pull request
Apr 21, 2026
This adds support to Effect v4, but also keeps the compatibility for v3.
There is no way that we can unit test against v3, as the
`devDependencies` need to use `effect@4` and an updated `@effect/vitest`
version, which is not compatible with Effect v3 (this is added in
The API for Effect v4 has changed a little, so there are safeguards to
detect if it is v3 or v4 and uses the correct API. The good part is that
for users nothing changed, so they still can use the same methods in
their app as before (ofc, respecting the new Effect v4 API).
Before (Effect v3):
```ts
const SentryLive = Layer.mergeAll(
Sentry.effectLayer({
dsn: '__DSN__',
tracesSampleRate: 1.0,
enableLogs: true,
}),
Layer.setTracer(Sentry.SentryEffectTracer),
Logger.replace(Logger.defaultLogger, Sentry.SentryEffectLogger),
Sentry.SentryEffectMetricsLayer,
);
```
After (Effect v4):
```js
const SentryLive = Layer.mergeAll(
Sentry.effectLayer({
dsn: '__DSN__',
tracesSampleRate: 1.0,
enableLogs: true,
}),
Layer.succeed(Tracer.Tracer, Sentry.SentryEffectTracer),
Logger.layer([Sentry.SentryEffectLogger]),
Sentry.SentryEffectMetricsLayer,
);
```
Both usages still work and are represented in the E2E tests.JPeer264 added a commit
that referenced
this pull request
Apr 21, 2026
This adds support to Effect v4, but also keeps the compatibility for v3.
There is no way that we can unit test against v3, as the
`devDependencies` need to use `effect@4` and an updated `@effect/vitest`
version, which is not compatible with Effect v3 (this is added in
The API for Effect v4 has changed a little, so there are safeguards to
detect if it is v3 or v4 and uses the correct API. The good part is that
for users nothing changed, so they still can use the same methods in
their app as before (ofc, respecting the new Effect v4 API).
Before (Effect v3):
```ts
const SentryLive = Layer.mergeAll(
Sentry.effectLayer({
dsn: '__DSN__',
tracesSampleRate: 1.0,
enableLogs: true,
}),
Layer.setTracer(Sentry.SentryEffectTracer),
Logger.replace(Logger.defaultLogger, Sentry.SentryEffectLogger),
Sentry.SentryEffectMetricsLayer,
);
```
After (Effect v4):
```js
const SentryLive = Layer.mergeAll(
Sentry.effectLayer({
dsn: '__DSN__',
tracesSampleRate: 1.0,
enableLogs: true,
}),
Layer.succeed(Tracer.Tracer, Sentry.SentryEffectTracer),
Logger.layer([Sentry.SentryEffectLogger]),
Sentry.SentryEffectMetricsLayer,
);
```
Both usages still work and are represented in the E2E tests.46 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds support to Effect v4, but also keeps the compatibility for v3. There is no way that we can unit test against v3, as the
devDependenciesneed to useeffect@4and an updated@effect/vitestversion, which is not compatible with Effect v3 (this is added in #20389).The API for Effect v4 has changed a little, so there are safeguards to detect if it is v3 or v4 and uses the correct API. The good part is that for users nothing changed, so they still can use the same methods in their app as before (ofc, respecting the new Effect v4 API).
Before (Effect v3):
After (Effect v4):
Both usages still work and are represented in the E2E tests.