Bug report
Environment
- Operating System: Ubuntu 24.04.4 LTS
- Python version: 3.12.3
Description of the bug
When a node in the endpoint's path has part of its name hardcoded and part set by environment variable, the rendered URL ignores the hardcoded part, keeping just the dynamic one. This leads to requests pointing to the wrong path and causing test errors.
Example:
scanapi.yaml:
endpoints:
- name: snippets-api
path: https://demo.scanapi.dev/api/v1/
headers:
Content-Type: application/json
requests:
- name: health
method: get
path: /heal${PATH_COMPLEMENT}/
With export PATH_COMPLEMENT=th, the expected result would be:
INFO HTTP Request: GET https://demo.scanapi.dev/api/v1/health/
Instead, the tool renders the URL ignoring the initial "heal" part of the node name and only collects the dynamically set value:
INFO HTTP Request: GET https://demo.scanapi.dev/api/v1/th/
How to reproduce the bug ?
Just need to create the scanapi.yaml as shown above, set the environment variable, and run it using scanapi's version 2.13.2.
Didn't test if the same issue happens in older versions.
Anything else we need to know?
Note: couldn't find anywhere mentioned if this is an expected way of using the variables, however I found out this bug while using the scanapi from openapi tool that generated tests with this pattern.
Bug report
Environment
Description of the bug
When a node in the endpoint's path has part of its name hardcoded and part set by environment variable, the rendered URL ignores the hardcoded part, keeping just the dynamic one. This leads to requests pointing to the wrong path and causing test errors.
Example:
scanapi.yaml:With
export PATH_COMPLEMENT=th, the expected result would be:Instead, the tool renders the URL ignoring the initial "heal" part of the node name and only collects the dynamically set value:
How to reproduce the bug ?
Just need to create the
scanapi.yamlas shown above, set the environment variable, and run it usingscanapi's version 2.13.2.Didn't test if the same issue happens in older versions.
Anything else we need to know?
Note: couldn't find anywhere mentioned if this is an expected way of using the variables, however I found out this bug while using the
scanapi from openapitool that generated tests with this pattern.