fix: Make signal in EventPublisherSubscribeIteratorOptions AbortSignal | undefined#928
fix: Make signal in EventPublisherSubscribeIteratorOptions AbortSignal | undefined#928dinwwwh merged 1 commit intomiddleapi:mainfrom
AbortSignal | undefined#928Conversation
…undefined`
If it isn't, while using the `signal` prop from the handler function, my typescript complains:
```
Argument of type '{ signal: AbortSignal | undefined; }' is not assignable to parameter of type 'EventPublisherSubscribeIteratorOptions' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
Types of property 'signal' are incompatible.
Type 'AbortSignal | undefined' is not assignable to type 'AbortSignal'.
Type 'undefined' is not assignable to type 'AbortSignal'.
```
Ref.: https://orpc.unnoq.com/docs/event-iterator#event-publisher
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughType-level update in EventPublisherSubscribeIteratorOptions: the signal property’s type changed from optional AbortSignal to optional AbortSignal | undefined. No runtime logic or control flow changes. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @boredland, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request resolves a TypeScript type incompatibility by explicitly allowing undefined for the signal property within the EventPublisherSubscribeIteratorOptions interface. This change addresses an error encountered when exactOptionalPropertyTypes is enabled, ensuring correct type inference and preventing compilation issues.
Highlights
- Type Definition Correction: Updated the
signalproperty inEventPublisherSubscribeIteratorOptionstoAbortSignal | undefinedto resolve a TypeScript error related toexactOptionalPropertyTypes.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
dosubot
bot
added
the
size:XS
There was a problem hiding this comment.
Code Review
This pull request correctly addresses a TypeScript typing issue that arises when the exactOptionalPropertyTypes compiler option is enabled. By changing the type of the signal property in the EventPublisherSubscribeIteratorOptions interface to AbortSignal | undefined, you've resolved the type incompatibility error described in the pull request. The change is minimal, targeted, and correct. I have no further feedback.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/shared/src/event-publisher.ts (2)
21-24: Document theexactOptionalPropertyTypesnuance in JSDocMinor doc tweak so consumers understand why
undefinedis allowed explicitly.export interface EventPublisherSubscribeIteratorOptions extends EventPublisherOptions { /** - * Aborts the async iterator. Throws if aborted before or during pulling. + * Aborts the async iterator. Throws if aborted before or during pulling. + * + * Accepts `AbortSignal | undefined` to interoperate with TypeScript's + * `exactOptionalPropertyTypes` (allows passing `{ signal: undefined }` explicitly). */ signal?: AbortSignal | undefined }
20-25: Unifysignal?: AbortSignaldeclarations across the repoI ran a repository-wide search and found multiple occurrences of optional
signalproperties with slightly different typings:
- packages/shared/src/event-publisher.ts (line 24):
signal?: AbortSignal | undefined- packages/shared/src/otel.ts (line 53):
signal?: AbortSignal- packages/client/src/types.ts (line 9):
signal?: AbortSignal- packages/server/src/middleware.ts (line 35):
signal?: AbortSignal- packages/server/src/procedure.ts (line 18):
signal?: AbortSignal- packages/server/src/procedure-client.ts (line 39):
signal?: AbortSignal(Additional matches exist in tests,
.d.tsstubs, and documentation, which you can ignore for the type consistency refactor.)To ensure consistent behavior under the
exactOptionalPropertyTypescompiler flag, I recommend standardizing all of these to the same form. We have two main options:
- Omit the explicit
| undefinedeverywhere (i.e. usesignal?: AbortSignal) since TypeScript already includesundefinedin optional properties.- Add
| undefinedeverywhere for explicitness, if that better fits your style guide.Most code here already uses the first style, so the simplest change is to remove the
| undefinedunion inevent-publisher.ts. If you’d prefer the explicit form, we can add| undefinedto the other four shared/client/server declarations instead.Let me know which approach you prefer—or I can prepare a small codemod to apply the change across all of them in this PR or a follow-up.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
packages/shared/src/event-publisher.ts(1 hunks)
🔇 Additional comments (1)
packages/shared/src/event-publisher.ts (1)
24-24: LGTM: type widening to support exactOptionalPropertyTypesChanging
signal?: AbortSignaltosignal?: AbortSignal | undefinedis the correct, backward-compatible fix forexactOptionalPropertyTypes. No runtime impact; aligns with how the option treats explicitundefined.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/experimental-durable-event-iterator
@orpc/hey-api
@orpc/interop
@orpc/json-schema
@orpc/nest
@orpc/openapi
@orpc/openapi-client
@orpc/otel
@orpc/react
@orpc/react-query
@orpc/experimental-react-swr
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-aws-lambda
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/standard-server-peer
@orpc/svelte-query
@orpc/tanstack-query
@orpc/trpc
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
2 participants
If it isn't, while using the
signalprop from the handler function, my typescript complains withexactOptionalPropertyTypesenabled:Ref.: https://orpc.unnoq.com/docs/event-iterator#event-publisher
Summary by CodeRabbit