bruno
bruno copied to clipboard
Pre Request vars in request not getting proper value
I have checked the following:
- [X] I use the newest version of bruno.
- [X] I've searched existing issues and found nothing related to my issue.
Describe the bug
My apologies if this is reported, my search skills did not render it. After version 1.14 of bruno, Pre Request vars that are used in the request do not have the proper value the first time they are called. They may have a value from another request or no value. Submitted the request a second time yields the expected results.
.bru file to reproduce the bug
meta { name: test type: http seq: 2 }
get { url: https://github.com/{{repository}} body: none auth: none }
vars:pre-request { repository: usebruno }
Screenshots/Live demo link
First submit
Second submit
Hey @PAllisonVSO
Thanks for bringing this to our attention. A fix for this issue will be included in the upcoming release. Thank you for your patience!
I have tested version 1.17.0. The variable does get assigned the first time, but if I change the value, the new value is is not used the first time. So it takes two clicks to get the proper value to be sent after the initial usage.
I have tested version 1.17.0. The variable does get assigned the first time, but if I change the value, the new value is is not used the first time. So it takes two clicks to get the proper value to be sent after the initial usage.
Hi @PAllisonVSO, I had the same problem, thank you for reporting it, you saved me some headache. Looks like the newest version 1.18.0, fixed the issue, can you confirm it?
@ggiambo I am still seeing this issue on version 1.18.0
@PAllisonVSO
The issue has been resolved in v1.18.0.
Please let me know if this is still an issue for you.
https://github.com/usebruno/bruno/assets/25679466/9b042c5e-57d0-4207-abbe-d04a55ea585f
@conor-carville
Could you please share a sample bru file to reproduce the issue you're facing ? That would be really helpful.
I am out of the office until next week. I will test it as soon as I can!
I have checked and verified that this issue is fixed as reported.