Using @resolveTo / sourceArgs with a Boolean parameter coerces value to always be `true`
### Issue workflow progress
<!-- PLEASE DO NOT REMOVE THIS SECTION -->
_Progress of the issue based on the
[Contributor Workflow](https://github.com/the-guild-org/Stack/blob/master/CONTRIBUTING.md#a-typical-contributor-workflow)_
- [ ] 1. The issue provides a reproduction available on
[Github](https://gist.github.com/ystros/02dba2e65fdc310f1075f0657566696f),
> Make sure to fork this template and run `yarn generate` in the terminal.
>
> Please make sure Mesh package versions under `package.json` matches yours.
- [ ] 2. A failing test has been provided
- [ ] 3. A local solution has been provided
- [ ] 4. A pull request is pending review
---
**Describe the bug**
<!-- A clear and concise description of what the bug is. -->
When a Boolean query parameter is used with a `sourceArgs` mapping, any false value is coerced to true when it reaches the API backend. This appears to be happening because `sourceArgs` uses string interpolation for non-object values (`false` boolean becomes `"false"` string), and then when the values are gathered for the backend API call it is coerced back into a boolean (`"false"` string evaluates to `true` boolean because non-empty strings are considered truthy regardless of content).
**To Reproduce** Steps to reproduce the behavior:
<!-- Adding a codesandbox can help us understand the bug better and speed up things -->
Define an internal query type (manually or through something like `createEncapsulateTransform`):
```
_internal_getProduct(
id: String!
boolean: Boolean
): Product @httpOperation(
subgraph: "mock"
path: "/api/products/{args.id}"
operationSpecificHeaders: [["accept", "application/json"]]
httpMethod: GET
queryParamArgMap: "{\"boolean\":\"boolean\"}"
) @source(name: "get_product", type: "Product", subgraph: "mock")
```
Create a query that references the internal one via `@resolveTo`, sourceFieldName and sourceArgs:
```
product(
id: String!
boolean: Boolean
): Product @resolveTo(
sourceName: "mock"
sourceTypeName: "Query"
sourceFieldName: "_internal_getProduct"
sourceArgs: {id: "{args.id}", boolean: "{args.boolean}"}
)
```
Run a query where the boolean value is set to `false`:
```
{ product(id: "abc", boolean: false) { id boolean } }
```
The value for `boolean` is set to `true` in the underlying API call:
```
[REST API] GET /api/products/abc?boolean=true
```
Small reproduction: https://gist.github.com/ystros/02dba2e65fdc310f1075f0657566696f
**Expected behavior**
<!-- A clear and concise description of what you expected to happen. -->
The value of the boolean query parameter should not be mutated.
The query:
```
{ product(id: "abc", boolean: false) { id boolean } }
```
Should result in the backend API call:
```
[REST API] GET /api/products/abc?boolean=false
```
**Environment:**
- OS: Mac OS
- `@graphql-mesh/string-interpolation`: 0.5.12
- `@graphql-hive/gateway-runtime`: 1.9.3
- `@graphql-mesh/transport-rest`: 0.9.14
- NodeJS: v25.3.0
**Additional context**
<!-- Add any other context about the problem here. -->
I believe this could either be fixed by special casing booleans in the string-interpolation package or where ever the result of the interpolation is rehydrated back to boolean
https://github.com/ardatan/graphql-mesh/blob/8f85b888336ec43aef0e9aab8097291eb83514b3/packages/string-interpolation/src/interpolator.js#L136-L160
Edit:
I have a commit that seems to fix this bug (when applied directly under `node_modules` of a larger project). It patches the interpolator to skip booleans in the same way it skips objects currently. I'm unsure how best to add a larger integration spec (or if one is desired in this case). Happy to open a PR.
https://github.com/ystros/graphql-mesh/commit/21e1b0d3cefae582120662409e89eabbec29f075
关闭于 2026-03-22 0 条评论