jc.variables.replaceIn Fails to Resolve Variables in Pre-request Scripts at Collection/Folder Level
Description
There is a critical issue where jc.variables.replaceIn() fails to resolve any variables — both Path Variables (e.g., {id}) and Environment/Collection Variables (e.g., {{var}}) — when the script is executed at the Collection or Folder level.
While the variables are correctly resolved by the application during the final request execution, the jc.variables.replaceIn method returns the raw, unparsed string when called from a high-level script. This prevents any pre-request logic (such as dynamic signing, custom logging, or header generation) from accessing the actual computed URL.
Steps to Reproduce
-
Create a Collection or Folder.
-
Add a Pre-request Script at the Collection/Folder level.
-
In the script, attempt to resolve a URL containing both path and environment variables:
console.log("Raw URL: " + jc.request.url);
var processedUrl = jc.variables.replaceIn(jc.request.url);
console.log("Processed URL: " + processedUrl);
-
Create a request within that folder using a URL such as:
{{gatewayUrl}}/api/v1/orders/{orderId}/status?type={{queryType}}
-
Ensure gatewayUrl, orderId, and queryType are defined in the Environment or Request Variables.
-
Run the request and observe the console output.
Observed Behavior
jc.variables.replaceIn returns the string exactly as it appears in the UI, without interpolating any values.
Console output:
jc.request.url:
{{gatewayUrl}}/api/v1/orders/{orderId}/status?type={{queryType}}
jc.variables.replaceIn(jc.request.url):
{{gatewayUrl}}/api/v1/orders/{orderId}/status?type={{queryType}}
Actual network call (resolved by the internal engine):
GET https://prod.api.app/api/v1/orders/ORD-8829/status?type=detailed
The engine correctly resolves all variables for the network call, but jc.variables.replaceIn fails to do so within the script context at the Collection/Folder hierarchy level.
Expected Behavior
jc.variables.replaceIn() should return a fully resolved string — with all {{...}} and {...} placeholders replaced by their current values — regardless of whether the script is running at the Request, Folder, or Collection level.
Impact
This bug blocks workflows that depend on the resolved URL for security-critical operations. For example, a Collection-level script that HMAC-signs the request URL will compute the signature against the raw template string (containing literal curly braces) rather than the actual URL. This results in signature mismatches and 401 Unauthorized errors from the server.
Environment
| Field |
Value |
| Project |
JetClient |
| Script Level |
Collection / Folder |
| Affected Method |
jc.variables.replaceIn() |
jc.variables.replaceInFails to Resolve Variables in Pre-request Scripts at Collection/Folder LevelDescription
There is a critical issue where
jc.variables.replaceIn()fails to resolve any variables — both Path Variables (e.g.,{id}) and Environment/Collection Variables (e.g.,{{var}}) — when the script is executed at the Collection or Folder level.While the variables are correctly resolved by the application during the final request execution, the
jc.variables.replaceInmethod returns the raw, unparsed string when called from a high-level script. This prevents any pre-request logic (such as dynamic signing, custom logging, or header generation) from accessing the actual computed URL.Steps to Reproduce
Create a Collection or Folder.
Add a Pre-request Script at the Collection/Folder level.
In the script, attempt to resolve a URL containing both path and environment variables:
Create a request within that folder using a URL such as:
Ensure
gatewayUrl,orderId, andqueryTypeare defined in the Environment or Request Variables.Run the request and observe the console output.
Observed Behavior
jc.variables.replaceInreturns the string exactly as it appears in the UI, without interpolating any values.Console output:
Actual network call (resolved by the internal engine):
Expected Behavior
jc.variables.replaceIn()should return a fully resolved string — with all{{...}}and{...}placeholders replaced by their current values — regardless of whether the script is running at the Request, Folder, or Collection level.Impact
This bug blocks workflows that depend on the resolved URL for security-critical operations. For example, a Collection-level script that HMAC-signs the request URL will compute the signature against the raw template string (containing literal curly braces) rather than the actual URL. This results in signature mismatches and
401 Unauthorizederrors from the server.Environment
jc.variables.replaceIn()