Referenced requests are not scoped to environment

[miquecg]

Expected Behavior

When I create a sub environment and define some value as the response from a given request, I expect the value to be tied to that particular environment.

Actual Behavior

I can see response values from the active environment in others.

Reproduction Steps

1. Create a sub environment and bind some field to some response
2. Set the environment as active
3. Execute that request so there is an actual value for the field
4. Create another sub environment with another field and try to bind it to the same type of response
5. Result is that value from the active environment is used when it should be empty

Is there an existing issue for this?

• [X] I have searched the issue tracker for this problem.

Additional Information

Previous work: #1895

Insomnia Version

2022.4.2

What operating system are you using?

Other (specify below)

Operating System Version

Arch Linux

Installation method

https://aur.archlinux.org/packages/insomnia-bin

Last Known Working Insomnia version

No response

[filfreire]

Hi @miquecg thank you for reporting this!

I'm able to reproduce this to some extent. Example bellow:

I define _.var in environment A and B as a chained request's response.

The chained request is just returning timestamp that I expected to be scoped and only renewed if the environment in scope does not have it.

And it ends up being the same across environments and not kept separate in scope:

The only alternative I found to this is in the Request Chaining config, to configure the request to always be resent:

But that still doesn't solve the fact that it's not properly scoped. Feel free to try and submit a PR if you notice any easy solution.

We will revisit these kinds of issues later this year, for now we're focused on introducing Websockets support to insomnia among other improvements. We'll update you here if we perform any changes related to this issue. @miquecg In the meantime feel free to report any other issues you come across 👍

[miquecg]

Thanks for taking time to verify the issue.

The only alternative I found to this is in the Request Chaining config, to configure the request to always be resent:

It makes sense because it will effectively hide previous changes and create new state each time.

Sorry that I cannot help anymore, I lack the time and skills to jump into JS/TS codebase.

[filfreire]

@miquecg no worries, it's a valid issue, adding it to our internal list of issues to fix 👍 We'll try to update you here if there's changes.

Like I said before, feel free to report any issues you find 😉

[miquecg]

Great :+1: