Insomnia: [Feature] Make it possible to resend request in a method chaining

[gilmishal]

Currently, chaining request values aren't updated unless the chained request is sent again manually. Which is fine, but it could be very useful if you could define cases to expire the existing value, forcing it to be reevaluated.

Assuming, I have a token value that is chained to a login request.
Every time I want to change the credentials/ token expired - I need to manually send the request.

In this example - I should be able to set that every 401 response for a request that uses the token parameter, or every change to the username or password parameters should expire the token, and force a reevaluation on the next request.

[AlainPilon]

Wouldnt just being able to run a JS snippet in a before/after hook on each request solve this (and add even more flexibility)?

[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.

[AlainPilon]

Am I the only one who think this is a good idea?

[gschier]

Going to reopen this. I do think it's a valuable feature to have. Just lost track of it in the sea of issues.

[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.

[huygn]

Would love to see this, initially I though chaining request would automatically do but then I realized I had to run the first request again.

[tadgh]

Agreed. With a lot of context switching between servers, it would help greatly to have the chained request rerun upon every request. Or at least a toggle allowing this to happen

[gschier]

Yep, this should definitely stay open

[Maxwell2022]

If this is not in the roadmap, I think the documentation should be updated to explicitly say that requests are actually not re-run (and a cached response from the first call is used).

When I saw chained requests, I expected the requests to be run each time I execute a test. In my case, the annoying thing is that my user token expires after 24 hours, so I have to run the auth manually everyday.

Also I agree with @tadgh, switching context is one of the other annoying thing.

[gschier]

How do you think this would be best configured? Here are the options:

• Add boolean toggle on the tag itself
• Add new tag (with possibly more chaining-specific options)
• Prompt user when sending the request
• Have another option when sending ("Send with dependencies")
• Request-level setting
• Workspace-level setting
• Global setting

_EDIT: GitHub really needs a voting mechanism_

[gschier]

Also, I totally agree no the docs confusion. It's called chaining now because I wasn't sure what else to call it and planed to add automatic dependency sending sooner.

[Maxwell2022]

I would either add a boolean or a cache expiration in ms that could be 0 for no cache. I think changing context should automatically break this cache, or store it under the context itself so you don't have to worry about it.

[RDeluxe]

Hello there.
I agree with @Maxwell2022 there, a cache expiration of 0 could replace the boolean.

[rgarrigue]

Hi

I'm also interested. And after a quick read, @Maxwell2022 proposal of a cache expiration seems good. Maybe with a prompt for the first usage, just in case triggering a request who trigger another one etc might end up taking too much resource.

[Tarig0]

Could we separate the dependency from the value retrieval? I have a case where I need to send a request before another to have the server change its state. Right now there is no way to "link" these two requests except for a dummy header.

[charlex]

Not to be just a +1, but this would be very helpful. Is there a status update on this?

[PTST]

How do you think this would be best configured? Here are the options:

• Add boolean toggle on the tag itself
• Add new tag (with possibly more chaining-specific options)
• Prompt user when sending the request
• Have another option when sending ("Send with dependencies")
• Request-level setting
• Workspace-level setting
• Global setting

_EDIT: GitHub really needs a voting mechanism_

An option for automatically resending the request when the request referencing the original response returns a 401, and also when changing environment would be nice.

[gschier]

🎁

[gschier]

I didn't implement the 401 logic but this can now (after the next app release) be done by forking the Response Plugin and making some slight tweaks for a new plugin with whatever behavior you want/need.

for example, to check the status code of the current request from within the response tag plugin:

async run(context, attribute, name, folderIndex) {
  const { meta, util } = context;

  if (!meta.requestId || !meta.workspaceId) {
    return null;
  }

  const response = await util.models.response.getLatestForRequestId(meta.requestId);

  if (!response) {
    return null;
  }

  const shouldResend = response.statusCode === 401;

  // Carry on...
}

Also, here's a link to the plugin docs if needed: https://support.insomnia.rest/article/26-plugins