Insomnia goes idle for 2 minutes before every request.

[Raibo]

Describe the bug We have to wait up to 2 minutes for a request to happen. On my PC it happens to be about 130 seconds. It was less, about 20-40 seconds before, now it's really hard to use.

When I hit "Send" button, "Loading" title appears for about a second, then time count starts and Insomnia goes idle.

During this idle period:

• Insomnia ignores the "Cancel" button, therefore request cannot be canceled.
• Other menus are available (for example, "Preferences", "Manage Environments")
• Insomnia process starts to require 15-40% CPU, doing seemingly nothing. (Intel Core i5-4690K)
• Application, which is supposed to receive the request, registers nothing coming. (Unlike insomnia, browser receive responses immediately for same endpoints)

After the request is done:

• From the moment it actually "happens", everything is ok.
• Insomnia shows timing (next to request status) not including the "Idle" period, several milliseconds.
• In "Timeline" tab, in "Current time is " statement, it shows time after the idle period passed.

To Reproduce Steps to reproduce the behavior:

1. Click 'Send' in any request. (It reproduces for any request)

Expected behavior Request starts immediately or shortly, in a few seconds.

Screenshots

Desktop:

• OS:
  1. Microsoft Windows [Version 10.0.18363.1621]
  2. MAC OS 2021.4.0
• Installation Method: -
• App Version: Insomnia 2021.4.0

[DFSko]

Confirm. I also have this problem

[costyn]

I also have a similar issue. Recently updated to 2021.4.1, and any New Requests I've added since then will time out after a minute with a 'Error: Server returned nothing (no headers, no data)' error. The exact same query in (for example) Postman instantly returns the correct data. Old requests still in Insomnia work ok. And funnily enough, if I edit the parameters of an old request to match the new one, it also works.

OS: Windows 10 Enterprise version 20H2 13/‎01/‎2021 App version: 2021.04.1

[dimitropoulos]

I was unable to reproduce this. Any tips? I sent a request to mockbin.org/delay/3000 and it started immediately and finished after the specified time.

[dimitropoulos]

Sorry to hear you're having this problem @LeoAlvesBahia and @DFSko and @Raibo -> could you please try making a complete backup of your insomnia data directory, then verifying that the files in your backup exactly match (really want to be careful here because you can destroy your data if not careful), and then opening insomnia fresh and trying again with a few new requests. I'm asking for this to make sure that it's nothing about your computer's environment. We'll keep debugging from there.

[LeoAlvesBahia]

@dimitropoulos Not a problem! We're to help each other. As I said on my post (Timer take too long after response to get out of screen #3955) I went through some instalation methods. Everytime when I went through a instalation method I erased the Insomnia data directory just to make sure that I did a 'clean' instalation.

[dimitropoulos]

Ohh. Interesting. Well now. That certainly raises suspicion. Thanks! (since you can uninstall and reinstall without deleting your data I didn't gather I wanted to verify).

1. Can you confirm that there's any older version of insomnia that did _not_have this problem (or, as @Raibo said above, at least had it less worse)?
2. This is a long shot, but I'm curious if any of you happen to have a virtual machine or dual boot on a machine that is having this issue? Don't go through the trouble if not, but I'd be curious to know if a dual boot on the same machine has the same problem in two different operating systems.

[LeoAlvesBahia]

1. The problem came with version 2021.4.1 the problem wasnt on earlier versions for me.
2. I do have dual boot on different HDs (Windows on SSD Manjaro on HD). I didnt make tests on Windows but I can do later.

[dimitropoulos]

That's very helpful. I'll see what I can dig up in the meantime. :)

[AlexeyShok]

@dimitropoulos I work for the same company as @Raibo. And I ran into the same problems. Did a little research. The requests use data from another request that receives the token. So when I just executed this token request separately, I saw on the screen that this request was called 22 times in 60 seconds and then only its result was shown on the screen. At the same time, Insomnia reported that this request was executed for 3 seconds, although in reality it worked for 63 seconds. I can assume that the problem is somewhere in the settings that are hidden in the databases of Insomnia. Unfortunately, sending these databases is problematic, as they contain confidential data. Could you provide some kind of tool for viewing and testing these databases in order to try to fix the error on the spot?

[LeoAlvesBahia]

Sorry for the delay. @dimitropoulos I forgot to test insomnia on WIndows. Ill do it in 20m max. Sorry about that. @AlexeyShok Im sorry but I cant. =// I use insomnia for work. I cant have the risk to send confidential data. But how would I do that? Maybe I can erase all data from here and make some tests with other APIs

[LeoAlvesBahia]

@dimitropoulos Same thing is happening on Windows! I exported a file from my insomnia on Linux. Before import the file I created some requests and tested, after 7 sends the problem appeared again the same way as my Linux boot. After that I imported the file and the problem still the same.

[dimitropoulos]

The requests use data from another request that receives the token.

Ohh, ok, so we're dealing with a chained request, then?

Is everyone else having this problem with a chained request. Do any other requests work (e.g. a GET to example.com)?

I saw on the screen that this request was called 22 times in 60 seconds and then only its result was shown on the screen.

Would it be possible for you to show a screenshot of this?

Could you provide some kind of tool for viewing and testing these databases in order to try to fix the error on the spot?

Not sure if it helps, but it's just new line delimited JSON (i.e. ndjson) and we use NeDB for the actual interaction with the data. It should be fairly easily to introspect. You could take a look at the files with https://github.com/AdrieanKhisbe/vscode-ndjson if you open them in vscode.

[LeoAlvesBahia]

Ohh, ok, so we're dealing with a chained request, then?

Yes BUT without chained requests the problem still persists with me. Just did a test to example.com with insomnia and postman. At Insomina the problem still persists and at postman just received the html page.

[dimitropoulos]

Before import the file I created some requests and tested, after 7 sends the problem appeared again

I see.. so @LeoAlvesBahia, to confirm, you installed insomnia fresh on Windows (i.e. for the first time, or after clearing your data directory) and before you did anything else you were able to get the bug to trigger after making a GET request to example.com. Right?

You've already done so much to help, but I'd love to verify that this happened with only one particular version. Would you be able to run a few of these and tell me if it still happens. It sounds like this happened first around the 2021.4.1 timeframe, but I'm wondering if it was also a problem before that (or not).

To make it easier for you, here are all of the windows portable builds since 2021.2.0:

• 2021.5.3
• 2021.5.2
• 2021.5.1
• 2021.5.0
• 2021.4.1
• 2021.4.0
• 2021.2.2
• 2021.2.1
• 2021.2.0

[LeoAlvesBahia]

you installed insomnia fresh on Windows

Yes!

before you did anything else you were able to get the bug to trigger after making a GET request to example.com

Not to example.com but yes! I didnt have Insomnia on my Windows partition.

I'd love to verify that this happened with only one particular version

I can do that but not right now. Just 9~10h from now. =/ When I do that I send the results here! Do you need that I do those tests on Linux aswell?

You've already done so much to help

I really like using Insomnia, I just hate not have this toll at my work days..! I really miss it. Heheh And Thanks for your help!

[dimitropoulos]

I can do that but not right now. Just 9~10h from now. =/

That's plenty fast! Thanks! I really appreciate it.

Do you need that I do those tests on Linux aswell?

Not for right now, especially since we're getting it to happen on all architectures. It's so much easier to test this with the portable builds, that if we can at least get this down to a particular version when the problem first appeared, that'll go a long way.

I really like using Insomnia

Wow, thanks! All of us on the team are really passionate about having the best experience for users that we possible can provide. This is a really frustrating problem, and I really value your patience in helping figure it out!

[DFSko]

Hello @dimitropoulos

Maybe this info help you Windows 11, Insomina 2021.5.3

Request: GET https://httpbin.org/get without chaining Request inside my new and clean collection takes 147ms Request inside my team shared collection takes more than 1 minute Team collection has 3 environments with many variables and many saved requests (maybe around one hundred)

[LeoAlvesBahia]

@dimitropoulos hello! I'm sorry for the delay. Right now I won't be able to make the tests. Still not at home. I need to get some sleep before get the road. A soon as I get home I do the tests!!

[LeoAlvesBahia]

Hello @dimitropoulos. Sorry for the 2 days delay. Im doing the tests right now and dicovered something new, I'll try to explain the best I can. Lets take the exemple where I do a send on requests2 and request2 is linked with request1. While on the screen of request2 is counting If I click on request1 this request have the new return (I can assure the return is new by the time from the top right) where I can get the data without problem while the request2 has the return but the time keep running. This is happening on all versions. The type of test that I did was just running all .exe that I downloed without erasing the data folder from windows. Next I'll erase the data folder before all tests and do GET request to exemple.com

I asked for a friend that Insomnia is working for him to import my export. My collection on his insomnia have the same problem but other collections are working fine.

[LeoAlvesBahia]

I had to stop the testing for now. I tested the version 2021.5.3 with the folder %APPDATA%/Insomnia erased. made around 10~15 GET to exemple.com and it did without any problem fast. Next I'll build a chained request from scratch to one of my working endpoints.

[dimitropoulos]

sorry for the silence, but we've been looking into this pretty much every day (in the mix of things!).

Are you using any plugins? If so, which ones (and versions)?

Are you using request chaining (with plugins or not)?

[eamigo86]

Hi, @dimitropoulos. In my case, I am not using plugins and the requests are chained (ex: for reuse auth token from other response body), although the same thing happens to others are chaining the requests.

[gatzjames]

Thanks everyone for helping us narrow this down!

@eamigo86, @DFSko are you using an environment and if so is it valid JSON? This shouldn't be possible through the UI so we'll need to investigate a bit more 🧐

[eamigo86]

Hi @gatzjames, Any progress with this? Right now it is impossible to use Insomnia with this issue.

https://user-images.githubusercontent.com/11740026/137567916-4991001a-01f6-4e54-8160-c1dee164af59.mp4

[eamigo86]

Hi @dimitropoulos, Any progress with this issue?

[develohpanda]

Hey folks, posting an update for you all! We've been debugging and exploring this issue for a few months now, and while we have some leads we still don't know for certain what is causing it. We also have not been able to reliably reproduce it except one specific workflow on Windows, which has been resolved with some changes we've made.

We have been exploring some underlying architectural changes to support newer versions of Electron, and while there are more changes to come in the coming months, we will be releasing the first batch of changes with the networking stack in the next week or so.

We think this change (https://github.com/Kong/insomnia/pull/4230) should help. Once the release is out we would appreciate if ya'll could please report back any findings, especially those of you who have been able to hit this issue consistently. Thank you!

[develohpanda]

Another update: we faced some issues with #4230 after release, so as of 2021.7.2 this has been reverted so is not part of the current stable release. We'll update this issue again when something is available to test, potentially via an alpha or beta release! Thank you all for your patience! 🙏🏽

[Vyoam]

I've an observation regarding delays due to chained requests, with a sample collection attached too. Might be relevant to this thread too. See: https://github.com/Kong/insomnia/issues/3011#issuecomment-1080368769

[Tubaleviao]

Happening with me as well~

[danielnieto]

Digging into this, seems like there's a performance issue with https://github.com/Kong/insomnia/blob/develop/packages/insomnia/src/common/database.ts#L579, but I think in reality it's NeDB the one crawling.

I edited network.ts file to add console.times to take the measures of the send function:

export async function send(
  requestId: string,
  environmentId?: string,
  extraInfo?: ExtraRenderInfo,
) {
  console.log(`[network] Sending req=${requestId} env=${environmentId || 'null'}`);
  // HACK: wait for all debounces to finish

  /*
   * TODO: Do this in a more robust way
   * The following block adds a "long" delay to let potential debounces and
   * database updates finish before making the request. This is done by tracking
   * the time of the user's last keypress and making sure the request is sent a
   * significant time after the last press.
   */
  const timeSinceLastInteraction = Date.now() - lastUserInteraction;
  const delayMillis = Math.max(0, MAX_DELAY_TIME - timeSinceLastInteraction);
  console.clear()
  console.time('delay')
  if (delayMillis > 0) {
    await delay(delayMillis);
  }
  console.timeEnd('delay')
  // Fetch some things

  console.time('get request')
  const request = await models.request.getById(requestId);
  console.timeEnd('get request')
  console.time('get settings')
  const settings = await models.settings.getOrCreate();
  console.timeEnd('get settings')
  console.time('get ancestors')
  const ancestors = await db.withAncestors(request, [
    models.request.type,
    models.requestGroup.type,
    models.workspace.type,
  ]);
    console.timeEnd('get ancestors')

  if (!request) {
    throw new Error(`Failed to find request to send for ${requestId}`);
  }
  console.time('getRenderedRequestAndContext')
  const renderResult = await getRenderedRequestAndContext(
    {
      request,
      environmentId,
      purpose: RENDER_PURPOSE_SEND,
      extraInfo,
    },
  );
  console.timeEnd('getRenderedRequestAndContext')

  const renderedRequestBeforePlugins = renderResult.request;
  const renderedContextBeforePlugins = renderResult.context;

  console.time('find workspaceDoc')
  const workspaceDoc = ancestors.find(isWorkspace);
  console.timeEnd('find workspaceDoc')
  console.time('get workspaceDoc')
  const workspace = await models.workspace.getById(workspaceDoc ? workspaceDoc._id : 'n/a');
  console.timeEnd('get workspaceDoc')
  if (!workspace) {
    throw new Error(`Failed to find workspace for request: ${requestId}`);
  }

  console.time('get env')
  const environment: Environment | null = await models.environment.getById(environmentId || 'n/a');
  console.timeEnd('get env')
  const responseEnvironmentId = environment ? environment._id : null;

  let renderedRequest: RenderedRequest;

  try {
    console.time('_applyRequestPluginHooks')
    renderedRequest = await _applyRequestPluginHooks(
      renderedRequestBeforePlugins,
      renderedContextBeforePlugins,
    );
    console.timeEnd('_applyRequestPluginHooks')
  } catch (err) {
    return {
      environmentId: responseEnvironmentId,
      error: err.message || 'Something went wrong',
      parentId: renderedRequestBeforePlugins._id,
      settingSendCookies: renderedRequestBeforePlugins.settingSendCookies,
      settingStoreCookies: renderedRequestBeforePlugins.settingStoreCookies,
      statusCode: STATUS_CODE_PLUGIN_ERROR,
      statusMessage: err.plugin ? `Plugin ${err.plugin.name}` : 'Plugin',
      url: renderedRequestBeforePlugins.url,
    } as ResponsePatch;
  }
  console.time('find certs')
  const clientCertificates = await models.clientCertificate.findByParentId(workspace._id);
  console.timeEnd('find certs')
  console.time('_actuallySend')
  const response = await _actuallySend(
    renderedRequest,
    clientCertificates,
    settings,
  );
  response.parentId = renderResult.request._id;
  response.environmentId = responseEnvironmentId;
  response.bodyCompression = null;
  response.settingSendCookies = renderedRequest.settingSendCookies;
  response.settingStoreCookies = renderedRequest.settingStoreCookies;
  console.timeEnd('_actuallySend')

  console.log(
    response.error
      ? `[network] Response failed req=${requestId} err=${response.error || 'n/a'}`
      : `[network] Response succeeded req=${requestId} status=${response.statusCode || '?'}`,
  );
  if (response.error) {
    return response;
  }
  console.time('_applyResponsePluginHooks')
  const res = _applyResponsePluginHooks(
    response,
    renderedRequest,
    renderedContextBeforePlugins,
  );
  console.timeEnd('_applyResponsePluginHooks')
  return res
}

Demo (has audio):

https://user-images.githubusercontent.com/2120107/196534831-cba2995f-ab79-41d8-8b63-eac4efed2d49.mp4

These are the results of a run which took ~60 seconds to complete:

getting the settings took 1.9 seconds, for this line: const settings = await models.settings.getOrCreate();

getting workspace took 2.6 seconds, for this line: const workspace = await models.workspace.getById(workspaceDoc ? workspaceDoc._id : 'n/a');

getting the environment took 1.4 seconds, this line: const environment: Environment | null = await models.environment.getById(environmentId || 'n/a');

getRenderedRequestAndContext took 31.7 seconds,

To compare, these are the results of another request with the exact same settings, that was immediately sent and shown:

[dselans]

Similar issues. Requests taking (seemingly randomly) from 1-10s while actual request time is <1s.

Simple GET requests against a Go rest'ish API service.

Has been happening for a few months.

Version: Insomnia 2022.6.0
Build date: 9/26/2022
OS: Darwin arm64 21.5.0
Electron: 19.0.3
Node: 16.14.2
V8: 10.2.154.4-electron.0
Architecture: arm64

[enricojonas]

We are looking into using Insomnia but facing similar issue, simple call takes around 4-6 seconds. Similar behavior with inso cli.

Using the latest release under Ubuntu 22.10:

Version: Insomnia 2022.7.5
Build date: 1/19/2023
OS: Linux x64 5.19.0-29-generic
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: x64

inso --version
3.12.0

Any findings / progress on this?

[duktig-dev]

For the first, Thank you very much for such a good product that you're supporting and giving as ability to use and enjoy!

We are also having the same issue:

Version: Insomnia 2023.1.0
Build date: 3/9/2023
OS: Darwin arm64 22.3.0 (macOS  Ventura 13.2.1 )
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: arm64

The request delays for more than one minute. The same request tested with other web clients and we are sure that the issue is inside the Insomnia.

Thank you.

[duktig-dev]

!!! Atansion !!! Who have issues with this request infinity delay ? I have found one tmp solution and it works perfect !

In the Settings window, General tab, add 100 to Request Timeout ms.

See the screenshot:

[rakhimali]

Hi Everyone! Here are the reasons why I switched to Insomnia from Postman.

1. You can quickly import curl from browsers devtools, this is a cool feature.
2. Insomnia is the best in terms of design and user interface, intuitive and this is amazing
3. I really liked the powerful functionality (using different environments and variables, chain requests), the presence of themes and plugins
4. Recommended to friends and colleagues, almost 90% switched to Insomnia

but now we have one annoyance / the problem still saddens: This is a long request processing time of almost 2 minutes, although in other clients such as Postman and Httpiness it completes in 1-2 seconds. I have huge collection: several separate environments, a couple of dozen variables, hundreds of saved requests, few installed plugins and themes, some requests are chained (first a token is requested, responseBody->token of this request it is used by another request). Absolutely any request is processed for a long time, which is why you have to use Postman to save time. The problem is observed in all versions of the client in Linux and in Windows tested on both systems, except for Mac OS. This is one of the problems that prevents Insomnia from being almost the best among rest clients. It's been almost 2 years since this problem was discovered, we live with this pain, there is a great hope that the developers will fix it so that we can safely recommend it to everyone.

[EG-ITz]

I had a similar problem testing a local service running on a different port than usual and @duktig-dev tip reduced execution time. Investigating why that tip partially solved the problem I discovered that the reason (in my case) is that I have an Insomnia project with a single collection where I declared REST methods for two different services (running on different port).

In the first service I use a variable on the path for login token generation. Insomnia seems to evaluate variables defined in collection methods at every API call, although the called API method doesn't use that variable at all. In fact, starting the first service, calls to second service become faster.

First service method on 8080 port (not running): Second running service without variable on different port:

Moving the 2nd API service to a different Insomnia collection solved my problem.

[s4ng]

Similar issue. Here is my solution. I removed the existing Document and created a new Collection. then it was solved.

[ihexxa]

Trying to improve this case a bit: #6763

[mwasif7]

I recently updated Insomnia to v8.6.1 and noticed a significant increase in the time it takes for requests to complete. The peculiar part is that the response time displayed in the output doesn’t match the actual time it takes for the request to complete. For instance, the output shows a response time of 590ms, but in reality, it takes over 50 seconds for the request to complete. Any workaround for the issue will be highly appreciated.

Already performed the basic troubleshooting: (OS: Windows)

• Uninstalled and re-installed the insomnia
• Deleted the %App Data%/insomnia folder
• Deleted all the cache related to insomnia from my machine

[subnetmarco]

We did make some improvements over time, can you please retest with the latest 9.3.2 (shipping in a few hours today) to see if this gets better?