You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm encountering an issue where variables defined in the YAML templates as JSON-formatted strings are not being parsed into JSON objects unless I set parse_response_as_json: true in the default_request or within the request step.
Steps to Reproduce
Use the variable in a request that expects a JSON object:
config:
...default_request:
product: '{{ product }}'steps:
- name: Test JSON Parsing in Variablesrequest:
product: '{ "id": 123 }'
Run the scenario:
poetry run ccheck --output-type console --filename test_scenario.yaml
Expected Behavior
The variable product should be parsed as a JSON object and sent in the request.
Actual Behavior
The variable product remains a string, not a parsed JSON object.
An error occurs when making a request to an API that sends a string in a JSON format.
Analysis
I traced the issue to the replace_str_with_json function in the codebase.
The function only attempts to parse strings into JSON if the parse_response_as_json flag is present in the dictionary.
Relevant Code Snippet:
I understand from the unit tests that the parse_response_as_json flag is intended to control when JSON parsing occurs, preventing unintended parsing of strings. However, in the case of variables, it seems cumbersome to set parse_response_as_json: true globally or within each request step.
Question
Variable Parsing Behavior: should variables containing JSON-formatted strings be parsed into JSON objects by default, or is there a recommended way to handle this?
Possible Solutions
Option 1: Modify the replace_str_with_json to automatically attempt to parse any variable value that is a string starting with a JSON opening character ({ or [), regardless of any flags.
Option 2: Introduce a new configuration option (e.g., parse_variables_as_json) that, when set to true, instructs the framework to parse all variables starting with { or [ as JSON.
I'm seeking guidance on the best way to handle variables that need to be parsed as JSON.
If introducing a new mechanism is acceptable, I'm happy to contribute by implementing it and submitting a Pull Request.
The text was updated successfully, but these errors were encountered:
Summary
I'm encountering an issue where variables defined in the YAML templates as JSON-formatted strings are not being parsed into JSON objects unless I set
parse_response_as_json: true
in thedefault_request
or within the request step.Steps to Reproduce
Expected Behavior
The variable product should be parsed as a JSON object and sent in the request.
Actual Behavior
The variable product remains a string, not a parsed JSON object.
An error occurs when making a request to an API that sends a string in a JSON format.
Analysis
I traced the issue to the
replace_str_with_json
function in the codebase.The function only attempts to parse strings into JSON if the
parse_response_as_json
flag is present in the dictionary.Relevant Code Snippet:
I understand from the unit tests that the
parse_response_as_json
flag is intended to control when JSON parsing occurs, preventing unintended parsing of strings. However, in the case of variables, it seems cumbersome to setparse_response_as_json: true
globally or within each request step.Question
Variable Parsing Behavior: should variables containing JSON-formatted strings be parsed into JSON objects by default, or is there a recommended way to handle this?
Possible Solutions
Option 1: Modify the
replace_str_with_json
to automatically attempt to parse any variable value that is a string starting with a JSON opening character ({
or[
), regardless of any flags.Option 2: Introduce a new configuration option (e.g.,
parse_variables_as_json
) that, when set to true, instructs the framework to parse all variables starting with{
or[
as JSON.I'm seeking guidance on the best way to handle variables that need to be parsed as JSON.
If introducing a new mechanism is acceptable, I'm happy to contribute by implementing it and submitting a Pull Request.
The text was updated successfully, but these errors were encountered: