insomnia
insomnia copied to clipboard
Kong
Insomnia goes idle for 2 minutes before every request.
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:
- Click 'Send' in any request. (It reproduces for any request)
Expected behavior Request starts immediately or shortly, in a few seconds.
Screenshots
Desktop:
- OS:
- Microsoft Windows [Version 10.0.18363.1621]
- MAC OS 2021.4.0
- Installation Method: -
- App Version: Insomnia 2021.4.0
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
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.
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.
@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.
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).
- 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)?
- 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.
- The problem came with version 2021.4.1 the problem wasnt on earlier versions for me.
- 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 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?
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
@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.
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.
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.
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:
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!
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!
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)
@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!!
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.
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.
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)?
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.
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 🧐
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
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!
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! 🙏🏽
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
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:
