Removing body depiction from negative response to HEAD requests
#2859
Conversation
WalkthroughThis change updates the handling of negative responses for HTTP HEAD endpoints by ensuring they return no body, aligning both type definitions and OpenAPI documentation accordingly. Supporting helper functions and tests are adjusted to treat all HEAD responses as body-less, regardless of response variant. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
Client->>API: HEAD /v1/user/retrieve
API-->>Client: Response headers (no body, regardless of error)
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes found. Possibly related PRs
Suggested labels
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
✨ 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. 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 (
|
![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
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
express-zod-api/tests/__snapshots__/documentation.spec.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (6)
example/example.client.ts(5 hunks)example/example.documentation.yaml(0 hunks)express-zod-api/src/common-helpers.ts(1 hunks)express-zod-api/src/documentation-helpers.ts(1 hunks)express-zod-api/src/integration.ts(1 hunks)express-zod-api/tests/common-helpers.spec.ts(1 hunks)
💤 Files with no reviewable changes (1)
- example/example.documentation.yaml
🧰 Additional context used
🧠 Learnings (5)
express-zod-api/src/integration.ts (3)
Learnt from: RobinTail
PR: #2736
File: express-zod-api/tsup.config.ts:12-26
Timestamp: 2025-06-14T16:42:52.972Z
Learning: In express-zod-api tsup configurations, the direct mutation of options.supported in the esbuildOptions callback is intentional behavior and should not be flagged as a side effect issue.
Learnt from: RobinTail
PR: #2428
File: express-zod-api/src/index.ts:44-44
Timestamp: 2025-05-28T18:58:10.064Z
Learning: The type-only import import type {} from "qs"; in express-zod-api/src/index.ts is necessary to avoid TS2742 errors for exported functions like attachRouting, makeRequestMock, testEndpoint, and testMiddleware that have types depending on @types/qs. This import provides the reference TypeScript needs to infer portable type names.
Learnt from: RobinTail
PR: #2833
File: express-zod-api/src/method.ts:3-3
Timestamp: 2025-07-20T11:09:58.980Z
Learning: In express-zod-api, the SomeMethod type (defined as Lowercase<string>) is intentionally broad to represent raw, unvalidated HTTP methods from requests. The narrower Method type is used after validation with isMethod(). This defensive programming pattern separates raw external input types from validated types, allowing graceful handling of unknown methods.
express-zod-api/src/common-helpers.ts (5)
Learnt from: RobinTail
PR: #2428
File: express-zod-api/src/index.ts:44-44
Timestamp: 2025-05-28T18:58:10.064Z
Learning: The type-only import import type {} from "qs"; in express-zod-api/src/index.ts is necessary to avoid TS2742 errors for exported functions like attachRouting, makeRequestMock, testEndpoint, and testMiddleware that have types depending on @types/qs. This import provides the reference TypeScript needs to infer portable type names.
Learnt from: RobinTail
PR: #2736
File: express-zod-api/tsup.config.ts:12-26
Timestamp: 2025-06-14T16:42:52.972Z
Learning: In express-zod-api tsup configurations, the direct mutation of options.supported in the esbuildOptions callback is intentional behavior and should not be flagged as a side effect issue.
Learnt from: RobinTail
PR: #2546
File: express-zod-api/src/json-schema-helpers.ts:75-87
Timestamp: 2025-05-27T20:40:19.548Z
Learning: In express-zod-api's flattenIO function in json-schema-helpers.ts, the additionalProperties field is used as a template to generate property schemas for literal property names extracted from propertyNames.const and propertyNames.enum. Converting boolean additionalProperties values to empty objects {} via Object(entry.additionalProperties) is intentional behavior, as the function only needs property schema templates, not the boolean semantics of additionalProperties.
Learnt from: RobinTail
PR: #2833
File: express-zod-api/src/method.ts:3-3
Timestamp: 2025-07-20T11:09:58.980Z
Learning: In express-zod-api, the SomeMethod type (defined as Lowercase<string>) is intentionally broad to represent raw, unvalidated HTTP methods from requests. The narrower Method type is used after validation with isMethod(). This defensive programming pattern separates raw external input types from validated types, allowing graceful handling of unknown methods.
Learnt from: RobinTail
PR: #2546
File: express-zod-api/src/io-schema.ts:5-8
Timestamp: 2025-05-28T05:04:40.327Z
Learning: The Base type object & { [Symbol.iterator]?: never } in express-zod-api correctly excludes arrays and other iterables from IOSchema. Arrays are properly rejected because they have a defined Symbol.iterator method which conflicts with the never constraint, as demonstrated by TypeScript compiler errors when attempting to assign z.array() to IOSchema.
express-zod-api/src/documentation-helpers.ts (2)
Learnt from: RobinTail
PR: #2736
File: express-zod-api/tsup.config.ts:12-26
Timestamp: 2025-06-14T16:42:52.972Z
Learning: In express-zod-api tsup configurations, the direct mutation of options.supported in the esbuildOptions callback is intentional behavior and should not be flagged as a side effect issue.
Learnt from: RobinTail
PR: #2428
File: express-zod-api/src/index.ts:44-44
Timestamp: 2025-05-28T18:58:10.064Z
Learning: The type-only import import type {} from "qs"; in express-zod-api/src/index.ts is necessary to avoid TS2742 errors for exported functions like attachRouting, makeRequestMock, testEndpoint, and testMiddleware that have types depending on @types/qs. This import provides the reference TypeScript needs to infer portable type names.
express-zod-api/tests/common-helpers.spec.ts (6)
Learnt from: RobinTail
PR: #2736
File: express-zod-api/tsup.config.ts:12-26
Timestamp: 2025-06-14T16:42:52.972Z
Learning: In express-zod-api tsup configurations, the direct mutation of options.supported in the esbuildOptions callback is intentional behavior and should not be flagged as a side effect issue.
Learnt from: RobinTail
PR: #2428
File: express-zod-api/src/index.ts:44-44
Timestamp: 2025-05-28T18:58:10.064Z
Learning: The type-only import import type {} from "qs"; in express-zod-api/src/index.ts is necessary to avoid TS2742 errors for exported functions like attachRouting, makeRequestMock, testEndpoint, and testMiddleware that have types depending on @types/qs. This import provides the reference TypeScript needs to infer portable type names.
Learnt from: RobinTail
PR: #2697
File: CHANGELOG.md:5-5
Timestamp: 2025-06-02T21:08:56.475Z
Learning: The cjs-test directory in the express-zod-api repository is a test workspace and should be excluded when checking for main project version consistency with changelog entries.
Learnt from: RobinTail
PR: #2546
File: express-zod-api/tests/buffer-schema.spec.ts:32-37
Timestamp: 2025-05-27T19:35:57.357Z
Learning: In the express-zod-api project, tests are run from the express-zod-api workspace directory, and the project uses an ESM-first environment without __dirname. Relative paths like ../logo.svg in test files correctly resolve to the repository root due to this test execution context.
Learnt from: RobinTail
PR: #2546
File: express-zod-api/tests/zts.spec.ts:160-162
Timestamp: 2025-05-27T20:22:30.428Z
Learning: In express-zod-api/tests/zts.spec.ts, the Fruits enum intentionally contains both string and numeric members (Apple = "apple", Banana = "banana", Cantaloupe = "cantaloupe", A = 5) and is used with z.enum(Fruits) to test how the system handles mixed enum types. This is by design for testing purposes.
Learnt from: RobinTail
PR: #2546
File: express-zod-api/src/json-schema-helpers.ts:75-87
Timestamp: 2025-05-27T20:40:19.548Z
Learning: In express-zod-api's flattenIO function in json-schema-helpers.ts, the additionalProperties field is used as a template to generate property schemas for literal property names extracted from propertyNames.const and propertyNames.enum. Converting boolean additionalProperties values to empty objects {} via Object(entry.additionalProperties) is intentional behavior, as the function only needs property schema templates, not the boolean semantics of additionalProperties.
example/example.client.ts (1)
Learnt from: RobinTail
PR: #2428
File: express-zod-api/src/index.ts:44-44
Timestamp: 2025-05-28T18:58:10.064Z
Learning: The type-only import import type {} from "qs"; in express-zod-api/src/index.ts is necessary to avoid TS2742 errors for exported functions like attachRouting, makeRequestMock, testEndpoint, and testMiddleware that have types depending on @types/qs. This import provides the reference TypeScript needs to infer portable type names.
🧬 Code Graph Analysis (4)
express-zod-api/src/integration.ts (1)
express-zod-api/src/common-helpers.ts (1)
doesImplyContent(145-145)
express-zod-api/src/common-helpers.ts (1)
express-zod-api/src/method.ts (1)
ClientMethod(35-35)
express-zod-api/src/documentation-helpers.ts (1)
express-zod-api/src/common-helpers.ts (1)
doesImplyContent(145-145)
express-zod-api/tests/common-helpers.spec.ts (1)
express-zod-api/src/common-helpers.ts (1)
doesImplyContent(145-145)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build (24.x)
- GitHub Check: build (20.9.0)
🔇 Additional comments (9)
express-zod-api/src/common-helpers.ts (1)
145-145: LGTM! Correctly implements HTTP HEAD standard behavior.The simplified logic correctly ensures that HEAD requests never imply content, regardless of response status. This aligns with HTTP standards where HEAD responses must always have an empty body, whether the response is successful (200) or an error (400/500).
express-zod-api/src/integration.ts (1)
110-110: LGTM! Correctly updated to match simplified function signature.The function call now properly matches the updated
doesImplyContentsignature, removing theresponseVariantparameter. The logic correctly determines content presence based on mimeTypes and method only.express-zod-api/tests/common-helpers.spec.ts (1)
339-341: LGTM! Test correctly verifies HEAD behavior.The test properly verifies that HEAD requests return false, aligning with the simplified function logic and HTTP standards.
express-zod-api/src/documentation-helpers.ts (1)
502-502: LGTM! Correctly updated for simplified function signature.The function call properly removes the
variantparameter to match the updateddoesImplyContentsignature. This ensures HEAD responses in OpenAPI documentation won't include content schemas regardless of response status.example/example.client.ts (5)
57-57: LGTM! Correctly implements HEAD response behavior.The change from a structured error object to
undefinedcorrectly reflects that HEAD responses should never contain body content, even for error cases.
196-196: LGTM! Consistent with HEAD response standards.Changing from
stringtoundefinedensures HEAD error responses don't include content, maintaining consistency with HTTP standards.
238-238: LGTM! Properly enforces empty HEAD response body.The type change ensures avatar endpoint HEAD errors return no content, aligning with the PR objective.
280-280: LGTM! Maintains consistent HEAD behavior.Stream endpoint HEAD error responses correctly changed to return no content.
393-393: LGTM! Completes consistent HEAD response handling.Events stream HEAD error responses now properly return no content, completing the consistent implementation across all endpoints.
Fixes #2858
Noticed by @coderabbitai in #2857 (comment)
Summary by CodeRabbit
Documentation
Refactor
Tests