Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling setEnvVar without converting response value to string results in crash when configuring environment #847

Closed
bjornevik opened this issue Nov 1, 2023 · 3 comments

Comments

@bjornevik
Copy link

Version: 1.0.0

A "crash" seems to be caused when using setEnvVar to set an environment variable to a response value which is not a string. This only seems to happen when setting equal to a value from the response. If using setEnvVar("value", 123456789) directly it works fine, but if 123456789 is part of the response-object it seems to not handle it correctly.

Example

Given the following response from an API:

{
  "value": 123456789,
}

The following script will cause a crash when clicking to configure environment:

const body = res.getBody()
bru.setEnvVar("value", body.value);

The following script will fill in the value as expected:

const body = res.getBody();
bru.setEnvVar("value", `${body.value}`)

Screenshots

With following postscript:
CleanShot 2023-11-01 at 13 14 08

After running query:
CleanShot 2023-11-01 at 13 18 28

Results in:
CleanShot 2023-11-01 at 13 15 11

@helloanoop
Copy link
Contributor

@bjornevik Usually strings are expected to be store in thesetEnvVar.
We should be able to fix this by doing a JSON.stringify() before saving and JSON.parse() before fetching

I need to think about this to see if there will be any effects.

Meanwhile, Can you use bru.setVar('key', val) and bru.getVar('name')
This allows storing full objects as well as exploring them in the Variable Viewer

image

@bjornevik
Copy link
Author

bjornevik commented Nov 1, 2023

Ah! I didn't realize that there was a separate collection variables tab, it seems more inline with most of my use cases. Thanks :D

@bjornevik
Copy link
Author

Seems like this was fixed in #1285

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants