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've searched existing issues and found nothing related to my issue.
Describe the bug
Context: For good integration of Bruno in our large team, we maintain URL variables like /foo/{{foo_id}}/bar as 'Pre Request' variables, which we commit empty and do not overwrite.
Since some update that I can no longer specify, this functionality is broken and variables stored in the pre-request are no longer set and are simply submitted empty instead. Staying with the previous example
Post url: /foo/{{foo_id}}/bar
Pre-request foo_id: 123
Actual requested URL: /foo//bar
Was this behaviour intentionally patched?
.bru file to reproduce the bug
meta {
name: Buggy pre variables test
type: http
seq: 1
}
post {
url: https://google.com/{{api}}
body: json
}
headers {
Content-Type: application/json
}
body:json {
{
"q": "{{query}}"
}
}
vars:pre-request {
api:
query:
}
Screenshots/Live demo link
shows the use of the defined 'Pre Request' variable 'api'.
shows that the pre-request variable 'api' has been set.
shows the timeline of the request and the empty replaced variables.
same as 3.
shows the current bruno version v1.21.0
The text was updated successfully, but these errors were encountered:
@Its-treason Thanks for the feedback, sorry I missed it when searching the open issues. I'm looking forward to the fix, as bruno is barely usable for us at the moment.
I have checked the following:
Describe the bug
Context: For good integration of Bruno in our large team, we maintain URL variables like
/foo/{{foo_id}}/bar
as 'Pre Request' variables, which we commit empty and do not overwrite.Since some update that I can no longer specify, this functionality is broken and variables stored in the pre-request are no longer set and are simply submitted empty instead. Staying with the previous example
/foo/{{foo_id}}/bar
123
/foo//bar
Was this behaviour intentionally patched?
.bru file to reproduce the bug
Screenshots/Live demo link
v1.21.0
The text was updated successfully, but these errors were encountered: