bugfix: Use merged request params to get request content-type#1227
bugfix: Use merged request params to get request content-type#1227am-burban wants to merge 1 commit intoacacode:mainfrom
Conversation
|
There was a problem hiding this comment.
Pull Request Overview
This PR ensures the Content-Type header is derived from the merged requestParams (including global defaults) instead of a local type variable.
- Updated test snapshots to expect
requestParams.typeinstead oftype. - Adjusted the fetch HTTP client template to use
requestParams.type.
Reviewed Changes
Copilot reviewed 26 out of 26 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tests/spec/**/__snapshots__/*.snap | Updated Content-Type header logic in snapshots to use requestParams.type |
| tests/__snapshots__/*.snap | Updated Content-Type header logic in snapshots to use requestParams.type |
| templates/base/http-clients/fetch-http-client.ejs | Use requestParams.type for Content-Type header in fetch client generator |
Comments suppressed due to low confidence (2)
templates/base/http-clients/js-http-client.ejs:183
- The axios HTTP client template still references the local
typevariable instead ofrequestParams.type, which will ignore defaults frombaseApiParams. Update this to userequestParams.typeto match the fetch client.
...(type && type !== ContentType.FormData ? { "Content-Type": type } : {})
templates/base/http-clients/fetch-http-client.ejs:186
- [nitpick] Consider extracting the Content-Type header merge logic into a shared helper or template partial to avoid duplicating this snippet across both fetch and axios client templates.
...(requestParams.type && requestParams.type !== ContentType.FormData ? { "Content-Type": requestParams.type } : {})
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Bugbot free trial expires on September 2, 2025
Learn more in the Cursor dashboard.
| headers: { | ||
| ...(requestParams.headers || {}), | ||
| ...(type && type !== ContentType.FormData ? { "Content-Type": type } : {}), | ||
| ...(requestParams.type && requestParams.type !== ContentType.FormData ? { "Content-Type": requestParams.type } : {}), |
There was a problem hiding this comment.
Bug: Content-Type Header Ignoring Method Parameters
The change to use requestParams.type for the Content-Type header means method-level type parameters are now ignored. Since type is destructured, it's not included in requestParams, breaking parameter precedence. This also creates an inconsistency, as the payload formatter still uses the original type parameter, leading to a mismatch between body formatting and the sent header.
2 participants
Hello 👋
I just noticed that to determine the content-type of a request, only the
typeparameter from therequestmethod itself is used. Atypeparameter provided in thebaseApiParamswhen instantiating theHttpClientis ignored. Imho it's a good idea to pull thetypefrom the merged request params, which also contain the global defaults.Best,
Ben