Insomnia: [Bug] Switching environments will re-use a stale chained request value

[qJake]

• Insomnia Version: 5.12.4
• Operating System: Windows 10 Pro (10.0.16299.125)

Details

If a workspace contains a chained request value (e.g. a bearer token) and there is more than one environment (e.g. development and staging), if a request is executed in development that requires a chained request value, that value will persist if switching to the other environments.

Steps to Reproduce

1. Create "Development" environment
2. Create "Staging" environment
3. Create POST request which retrieves OAuth 2.0 Bearer token
4. Create GET request which requires Authorization: Bearer <token> header
5. Fill Auth Bearer Token value with Response => Body Attribute macro, executing the POST Token request from Step 3.
6. Execute request, and ensure bearer token was used in the request successfully
7. Switch environments
8. Execute the same request. Note that the previous bearer token was cached and used as part of the request (and, presumably, you will get either a 400 Bad Request or 401 Unauthorized error).

[welcome[bot]]

👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

[gschier]

Hi @qJake, thanks for the great issue report!

To clarify, this is not a bug but a limitation of the feature. The Response => Body Attribute simply pulls the value from the latest response of that request, meaning it has no concept of environments.

I think this can actually be treated as a larger issue with environments in general. Perhaps environments should affect the user's workflow more than they do? For example, only showing responses sent using the currently-active environment would prevent this from being an issue _and_ possibly even be the desired outcome.

P.S. This does not solve the problem, but I'm curious... How come you are not using the official OAuth 2.0 support?

[qJake]

We interface with a custom third-party API we don't control, and they don't implement "proper" OAuth 2.0. I wish we could use it. 😄

I'm curious - you said it only pulls the last response from the referenced request - if there is no response, does it execute that request first in the background?

If so, would it be possible to just delete the "cache" upon an environment switch, so to speak? Or would that mess up some other use cases for environments...?

If it helps, I consider an environment an isolated entity - I would not want my staging responses being used in development, or worse, my production responses used somewhere else inadvertently. (Granted, this is just a random bearer token, but still.) We also use the environment switcher for accessing different client servers occasionally (we're talking a dozen or so, sometimes less) - so obviously any persistent data between those environments could present a problem (at the very least, auth won't work, as I reported ⏫).

For what it's worth, we just switched from Postman and I'm already loving Insomnia a lot more, so keep up the great work!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qJake]

Could this be marked as an enhancement for future work on environments? I just don't want it to get closed - I think it's still a viable addition to Insomnia!

[devinsba]

I just ran into this using the official OAuth 2 support, it was completely unexpected. I certainly would like the "responses from one environment not available in another" feature. Would love to see that

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qJake]

Bad stale bot! Bad!

Paging @gschier - can we switch this to an enhancement request so it doesn't get closed? Would love to see this functionality improve in future versions!

[gschier]

Yep, now it won't close 😄

[jmillxyz]

FWIW I just ran into the same issue -- we use bearer JWT tokens with multiple environments (dev, staging, prod, etc) and tokens are generated by scoping them to a single environment. Caching them across environments in my case was unexpected. What's the best way for us to help with this @gschier ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qJake]

Bad bot! No stale tag! This is still something I'd love to see - essentially having the history / response cache be per-environment instead of global. Would have numerous benefits!

[gschier]

Sorry about that. I was changing up the issue tag descriptions so the stale bot went on a rampage!

[qJake]

I have a follow-up suggestion to this that may work or be a bit easier to implement with regards to the suggestion above...

I noticed a new feature, Trigger Behavior, on the Response function. Would it be possible to add a new Trigger Behavior called "On Environment Change" that would cause the request to re-execute if the user switched environments? This would satisfy my previous concern about cross-contaminating environments and auth tokens.

Thoughts?

[fcottet]

This is very similar to issue #260
It would be awesome to see these 2 questions solved in a similar manner - like an option at the workspace level to reset all the stored responses/tokens when switching between environments.