feat(client, contract, openapi): support 3xx response#304
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis pull request introduces a new documentation page and sidebar item for handling HTTP redirect responses within the OpenAPI context. It also updates several client and adapter modules to refine error handling by replacing range checks with the Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant LinkFetchClient
participant FetchAPI
participant ErrorChecker
Client->>LinkFetchClient: Initiate fetch request
LinkFetchClient->>FetchAPI: fetch(request, {redirect: 'manual'})
FetchAPI-->>LinkFetchClient: Return response (status code)
LinkFetchClient->>ErrorChecker: isORPCErrorStatus(response.status)
ErrorChecker-->>LinkFetchClient: Boolean result
LinkFetchClient-->>Client: Return processed response/error
sequenceDiagram
participant Caller
participant ContractProcedure
participant ErrorValidator
Caller->>ContractProcedure: Create procedure(def)
ContractProcedure->>ErrorValidator: isORPCErrorStatus(successStatus)
ErrorValidator-->>ContractProcedure: Validation result
alt Validation fails
ContractProcedure-->>Caller: Throw error "[ContractProcedure] Invalid successStatus."
else Validation passes
ContractProcedure-->>Caller: Initialize procedure successfully
end
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/openapi
@orpc/openapi-client
@orpc/react-query
@orpc/contract
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/svelte-query
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/content/docs/openapi/advanced/redirect-response.md (1)
1-34: Clear and concise documentation for redirect responses!The documentation effectively explains how to implement HTTP redirects in oRPC OpenAPI with a practical example and important limitations note.
Consider enhancing this documentation with:
- Examples of other redirect status codes (301, 302, 303, 308) and when to use each
- A complete example showing both client and server-side code
- Code snippets demonstrating how to properly handle redirects in client code
packages/contract/src/procedure.ts (1)
33-34: Consider using optional chaining for more robustness.The validation looks good, but consider using optional chaining to make the code more robust against null or undefined values.
-if (Object.values(def.errorMap).some(val => val && val.status && !isORPCErrorStatus(val.status))) { +if (Object.values(def.errorMap).some(val => val?.status && !isORPCErrorStatus(val.status))) { throw new Error('[ContractProcedure] Invalid error status code.') }🧰 Tools
🪛 Biome (1.9.4)
[error] 33-33: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
apps/content/.vitepress/config.ts(1 hunks)apps/content/docs/openapi/advanced/redirect-response.md(1 hunks)packages/client/src/adapters/fetch/index.ts(0 hunks)packages/client/src/adapters/fetch/link-fetch-client.test.ts(1 hunks)packages/client/src/adapters/fetch/link-fetch-client.ts(2 hunks)packages/client/src/adapters/fetch/types.ts(0 hunks)packages/client/src/adapters/standard/rpc-link-codec.test.ts(3 hunks)packages/client/src/adapters/standard/rpc-link-codec.ts(2 hunks)packages/client/src/error.test.ts(3 hunks)packages/client/src/error.ts(2 hunks)packages/contract/src/procedure.test.ts(1 hunks)packages/contract/src/procedure.ts(2 hunks)packages/openapi-client/src/adapters/standard/openapi-link-codec.test.ts(3 hunks)packages/openapi-client/src/adapters/standard/openapi-link-codec.ts(2 hunks)
💤 Files with no reviewable changes (2)
- packages/client/src/adapters/fetch/index.ts
- packages/client/src/adapters/fetch/types.ts
🧰 Additional context used
🧬 Code Definitions (5)
packages/client/src/adapters/standard/rpc-link-codec.ts (1)
packages/client/src/error.ts (1)
isORPCErrorStatus(177-179)
packages/openapi-client/src/adapters/standard/openapi-link-codec.test.ts (2)
packages/client/src/error.ts (1)
ORPCError(100-160)packages/openapi-client/src/adapters/standard/openapi-link-codec.ts (1)
StandardOpenapiLinkCodec(31-242)
packages/contract/src/procedure.ts (1)
packages/client/src/error.ts (1)
isORPCErrorStatus(177-179)
packages/client/src/adapters/standard/rpc-link-codec.test.ts (1)
packages/client/src/error.ts (1)
ORPCError(100-160)
packages/openapi-client/src/adapters/standard/openapi-link-codec.ts (1)
packages/client/src/error.ts (1)
isORPCErrorStatus(177-179)
🪛 GitHub Actions: CI
packages/client/src/adapters/fetch/link-fetch-client.ts
[error] 10-10: error TS2304: Cannot find name 'RequestRedirect'.
🪛 Biome (1.9.4)
packages/contract/src/procedure.ts
[error] 33-33: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (25)
apps/content/.vitepress/config.ts (1)
194-194: Well-structured sidebar addition!The new sidebar item for "Redirect Response" is appropriately placed in the Advanced section and follows the established naming and linking patterns.
packages/client/src/adapters/fetch/link-fetch-client.test.ts (1)
43-43: Added redirect handling to support 3xx responsesThe addition of
{ redirect: 'manual' }configures the fetch request to not automatically follow redirects, allowing the client to handle 3xx responses manually. This change is consistent with the PR objective of supporting HTTP redirect responses.packages/client/src/error.test.ts (3)
1-1: Updated import to include the new isORPCErrorStatus functionThe import statement is properly updated to include the newly added
isORPCErrorStatusfunction.
45-47: Updated test case to validate new error status behaviorThe test case has been modified to reflect the change in how error status codes are defined, now treating 399 as a non-error status and 400 as an error status. This is consistent with the new
isORPCErrorStatusfunction implementation.
111-118: Added test for the new isORPCErrorStatus functionThe test correctly validates that:
- Status codes 200 and 399 (2xx and 3xx) are NOT considered error statuses
- Status codes 400, 499, and 199 (4xx, 400+, and <200) ARE considered error statuses
This ensures the function behaves as expected for HTTP redirect (3xx) responses.
packages/client/src/error.ts (2)
107-109: Updated error validation to use new isORPCErrorStatus functionThe constructor now uses the
isORPCErrorStatusfunction to validate the status code, making the validation logic more maintainable and consistent throughout the codebase.
177-179: Added isORPCErrorStatus function to standardize error status checkingThis new function provides a centralized way to determine if a status code is an error in the ORPC context. The implementation correctly identifies:
- Non-error status codes: 2xx and 3xx (≥ 200 and < 400)
- Error status codes: < 200 and ≥ 400
This is a key enabler for properly handling 3xx redirect responses as non-error responses.
packages/client/src/adapters/standard/rpc-link-codec.ts (2)
6-6: Updated import to include isORPCErrorStatus functionThe import statement is correctly updated to include the new utility function.
120-120: Improved status code checking to support 3xx responsesThe decode method now uses the
isORPCErrorStatusfunction to determine if a response is successful, replacing the previous range check that only allowed 2xx responses. This enables the codec to properly treat 3xx responses as non-error responses, fulfilling the PR objective.packages/client/src/adapters/standard/rpc-link-codec.test.ts (3)
2-2: Import and spy setup looks good.The import change and creation of
isORPCErrorStatusSpymakes sense here to facilitate testing the error status handling functionality.Also applies to: 7-8
127-128: Good test coverage for success status checking.Adding assertions to verify that
isORPCErrorStatusis called with the correct status code improves the test's coverage of the error handling logic.
153-154: Good test coverage for error status checking.Similar to the success case, these assertions ensure that
isORPCErrorStatusis properly called when handling error statuses.packages/contract/src/procedure.test.ts (3)
1-1: Test setup looks good.The import change and the spy setup for
isORPCErrorStatusalong with test cleanup inbeforeEachfollow best practices for testing.Also applies to: 5-9
12-31: Good test coverage for successStatus validation.The test now properly validates the behavior of the constructor with both valid and invalid status codes, ensuring that
isORPCErrorStatusis called with the correct arguments.
33-60: Good test coverage for errorMap validation.The test ensures that the constructor validates status codes in the errorMap correctly, throwing an error for success statuses (200) and accepting error statuses (500).
packages/contract/src/procedure.ts (2)
5-5: Good addition of the import.Importing
isORPCErrorStatusfrom@orpc/clientaligns with using a standardized approach to error status validation.
29-30: Good update to validation logic.Using
isORPCErrorStatusprovides better standardization of error handling across the codebase compared to hardcoded range checks.packages/client/src/adapters/fetch/link-fetch-client.ts (1)
29-29: Good implementation of manual redirect handling.Setting
redirect: 'manual'is appropriate for handling 3xx responses explicitly, which aligns with the PR objective.packages/openapi-client/src/adapters/standard/openapi-link-codec.ts (2)
4-4: Import updated to support 3xx response handlingThe import statement has been updated to include the
isORPCErrorStatusfunction as a value import rather than just importing types. This change supports the new redirect handling functionality.
189-189: Improved status code handling to support HTTP redirectsThe change from explicitly checking status codes in the 200-299 range to using
!isORPCErrorStatus(response.status)is a significant enhancement. This now allows 3xx responses (redirects) to be treated as successful responses rather than errors, which aligns with the PR's objective.Looking at the implementation of
isORPCErrorStatus, this function returns true only for status codes < 200 or >= 400, meaning 3xx codes are no longer considered errors.packages/openapi-client/src/adapters/standard/openapi-link-codec.test.ts (5)
1-1: Updated module import approachChanged from individual imports to a namespace import for better organization and to support spying on module functions.
9-10: Added test utility setup for error status checkingExtracting the
ORPCErrorand creating a spy onisORPCErrorStatusenables proper testing of the new 3xx response handling functionality.
288-289: Added test verification for successful 201 responseThese assertions verify that the
isORPCErrorStatusfunction is called with the correct status code (201) and that non-error responses are properly handled in the compact output structure case.
309-311: Added test verification for detailed output structureSimilar to the compact output test, these assertions verify that
isORPCErrorStatusis correctly used to determine successful responses in the detailed output structure case.
313-348: Added comprehensive test case for error handlingThis new test case thoroughly verifies:
- Proper handling of error responses with valid ORPC error format (status 501)
- Proper handling of error responses with malformed format (status 409)
- Correct call count and parameters for the
isORPCErrorStatusfunctionThe test enhances coverage for the error handling logic while supporting the new 3xx response handling.
1 participant
Summary by CodeRabbit
Documentation
New Features
Bug Fixes