feat(effect): update integration to Effect V4#1603
Conversation
dosubot
Bot
added
the
size:L
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
dosubot
Bot
added
dependencies
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughUpdates the Effect integration package, related tests, docs, and workspace constraints for the Effect v4 beta API surface. The changes cover schema conversion types, yield typing, runtime error handling, service declarations, and example code. ChangesEffect v4 Upgrade
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the project's integration with the effect library to version 4 (beta), adapting the codebase to several API changes including replacing Context.Tag with Context.Service, migrating to standard schema methods, and removing YieldWrap from type signatures. The review feedback suggests leveraging the predicate form of Effect.catch to handle ORPCErrors more cleanly, and restoring the use of FiberId.threadName to prevent potential stringification issues when reporting interrupted fibers.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/effect/package.json (1)
54-54: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueBeta peer range admits breaking betas.
>=4.0.0-beta.86 <5will satisfy any later Effect v4 beta/RC, but Effect v4 is pre-stable and beta-to-beta changes can break the APIs this package now relies on (toStandardSchemaV1,toStandardJSONSchemaV1,ConstraintDecoder). Consider an upper bound on the beta line (e.g.>=4.0.0-beta.86 <4.0.0-rc / pinning to a tested beta band) until v4 stabilizes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/effect/package.json` at line 54, The peer dependency range for the Effect package is too broad and can admit later breaking beta/RC releases. Tighten the version constraint in the package manifest for the effect dependency used by the package so it stays within a tested v4 beta band or caps before stable/RC releases, and keep the range aligned with the APIs relied on here such as toStandardSchemaV1, toStandardJSONSchemaV1, and ConstraintDecoder.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/effect/package.json`:
- Line 54: The peer dependency range for the Effect package is too broad and can
admit later breaking beta/RC releases. Tighten the version constraint in the
package manifest for the effect dependency used by the package so it stays
within a tested v4 beta band or caps before stable/RC releases, and keep the
range aligned with the APIs relied on here such as toStandardSchemaV1,
toStandardJSONSchemaV1, and ConstraintDecoder.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 77487a3e-4298-4095-8c3f-1c2f6adbfce3
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (12)
apps/content/docs/integrations/effect.mdapps/content/package.jsonpackages/effect/package.jsonpackages/effect/src/converter.tspackages/effect/src/extensions/effect.tspackages/effect/src/extensions/input-output.test-d.tspackages/effect/src/extensions/input-output.tspackages/effect/src/handler.test-d.tspackages/effect/src/handler.test.tspackages/effect/src/handler.tspackages/effect/src/runtime.tspackages/effect/src/schema.ts
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — migration of @orpc/experimental-effect and its docs from Effect v3 to Effect v4.
- Bumped
effectrange to>=4.0.0-beta.86 <5inpackages/effectandapps/content. - Migrated schema conversion APIs to
Schema.toStandardSchemaV1andSchema.toStandardJSONSchemaV1. - Updated input/output overloads to use
Schema.ConstraintDecoder<any, never>and map itsEncoded/Typemembers. - Replaced
YieldWrapwith directEffect.Effectyields and updated error handling (Effect.catch,Effect.catchCause,Cause.squash,Context.Service). - Updated Effect examples in
apps/content/docs/integrations/effect.md.
openrouter/moonshotai/kimi-k2.7-code (free via Pullfrog for OSS) ｜ 𝕏
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/effect/package.json`:
- Line 54: The peer dependency range for effect is too open and can resolve to
v5 unexpectedly; tighten the peerDependencies.effect constraint in package.json
to keep this package on the v4-beta contract. Update the existing effect version
range to include an upper bound below 5 while preserving the current minimum,
and ensure the change is applied in the package.json peerDependencies entry for
effect.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 750f33a3-c665-4bec-bef0-9f4c22f1adad
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (6)
apps/content/package.jsonpackages/effect/package.jsonpackages/effect/src/runtime.test.tspackages/effect/src/runtime.tspackages/effect/src/schema.tspnpm-workspace.yaml
✅ Files skipped from review due to trivial changes (1)
- pnpm-workspace.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/effect/src/schema.ts
| convert(schema: AnySchema | undefined, direction: JsonSchemaConverterDirection): [jsonSchema: JsonSchema, optional: boolean] { | ||
| const effectSchema = schema as unknown as EffectSchema.Schema<any, any> & AnySchema | ||
| const jsonSchema = JSONSchema.make(effectSchema, { target: 'jsonSchema2020-12' }) | ||
| const effectSchema = schema as EffectSchema.Unknown & AnySchema |
There was a problem hiding this comment.
I really don't like this approach. It seems Effect doesn't support draft-2020-12, so there's no built-in way to handle it. Also, the draft-2020-12 type here comes only from the standard JSON Schema specification might not work or ignored by effect.
There was a problem hiding this comment.
I checked the Effect code, and I think they do actually support draft-2020-12.
...jsonSchema.input({ target: "draft-2020-12" }) calls toBaseStandardJSONSchemaV1, which first calls toJsonSchemaDocument. That function returns JsonSchema.Document<"draft-2020-12"> and sets dialect: "draft-2020-12". For the "draft-2020-12" target, Effect returns that schema directly and moves definitions to $defs.
That said, I agree that it isn't ideal and relies too much on Effect internals. Instead, it now only calls Schema.toStandardJSONSchemaV1 to attach Effect’s Standard JSON Schema support, then delegates the actual JSON Schema generation to oRPC's existing StandardJsonSchemaConverter.
I also added a test with Schema.NumberFromString to verify that input/output conversion direction is preserved through that path.
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/experimental-effect
@orpc/evlog
@orpc/interop
@orpc/json-schema
@orpc/next
@orpc/openapi
@orpc/opentelemetry
@orpc/pino
@orpc/publisher
@orpc/ratelimit
@orpc/server
@orpc/shared
@orpc/tanstack-query
@orpc/valibot
@orpc/zod
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
test
Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
|
Important The Effect peer dependency range is now unbounded and will admit incompatible future major versions. Reviewed changes — since the prior review, the PR pinned Effect to
|
* Use ORPCs own `StandardJsonSchemaConverter` instead of effect's built-ins.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/effect/src/converter.ts`:
- Around line 8-16: The JSON conversion path in converter.ts is using a
non-existent EffectSchema.toStandardJSONSchemaV1 API and an incorrect cast to
EffectSchema.Constraint. Update convert(...) to work with the already validated
standard schema from schema['~standard'] and use the proper Effect Schema JSON
conversion API, such as Schema.toJSONSchema or Schema.standardSchemaV1, then
pass that result to standardJsonSchemaConverter.convert. Keep the fix localized
to the condition(...) / convert(...) logic so the converter handles AnySchema
consistently without the invalid Constraint cast.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: cda74b65-f836-4a76-8267-087c60efd57d
📒 Files selected for processing (2)
packages/effect/src/converter.test.tspackages/effect/src/converter.ts
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — refactored Effect JSON-schema conversion to delegate input/output generation and optional detection to @orpc/json-schema's shared converter.
- Replaced the inline
JSONSchema.make+ manual optional check inEffectSchemaToJsonSchemaConverterwith a call toStandardJsonSchemaConverter.convert, reusing the same logic that handles other standard-schema libraries. - Added tests verifying effect's standard-JSON-schema input/output generators and that conversion survives a throwing
~standard.validate.
Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
Updated
@orpc/experimental-effectto support Effect V4.Summary by CodeRabbit
runPromiseinterruption behavior to report consistent abort errors (including honoring a provided abort reason).