-
Notifications
You must be signed in to change notification settings - Fork 1.9k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
[Bug] Switching environments will re-use a stale chained request value #669
Comments
👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure To help make this a smooth process, please be sure you have first read the |
Hi @qJake, thanks for the great issue report! To clarify, this is not a bug but a limitation of the feature. The 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? |
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! |
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. |
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! |
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 |
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. |
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! |
Yep, now it won't close 😄 |
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 ? |
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. |
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! |
Sorry about that. I was changing up the issue tag descriptions so the stale bot went on a rampage! |
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? |
This is very similar to issue #260 |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Authorization: Bearer <token>
headerResponse => Body Attribute
macro, executing the POST Token request from Step 3.The text was updated successfully, but these errors were encountered: