Error: connect ETIMEDOUT error when used in node.js

[wictorwilen]

I get the following error in my node.js application after the application is supposed to end. It's a node.js application (14.7.6) running in WSL2. It successfully sends multiple traces, but after complete it times out for a minute and half.

This is the log from AI:

ApplicationInsights:Sender [ '{"itemsReceived":1,"itemsAccepted":1,"errors":[]}' ]
ApplicationInsights:Sender [
  {
    method: 'POST',
    withCredentials: false,
    headers: {
      'Content-Type': 'application/x-json-stream',
      'Content-Encoding': 'gzip',
      'Content-Length': '364'
    }
  }
]
ApplicationInsights:Sender [
  `{"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"103: Field 'time' on type 'Envelope' is older than the allowed min date. Expected: now - 172800000ms, Actual: now - 5847774407ms"}]}`
]
ApplicationInsights:AzureVirtualMachine [
  Error: connect ETIMEDOUT 169.254.169.254:80
      at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
      at TCPConnectWrap.callbackTrampoline (internal/async_hooks.js:131:17) {
    errno: -110,
    code: 'ETIMEDOUT',
    syscall: 'connect',
    address: '169.254.169.254',
    port: 80
  }
]

[hectorhdzg]

ETIMEDOUT is by design, we try to call local IP in Azure environments to get information about the machine, if you run outside of Azure you will see this error once, regarding the error with 400 response, it means you are trying to send telemetry with really old timestamps, do you get consistent repro of that?, to avoid app to not end immediately you can configure the SDK to not use HTTP Agent with keepalive=true using noHttpAgentKeepAlive config

[wictorwilen]

Thanks. We can ignore the 400 issue - I got that covered.

But the ETIMEDOUT scares me - what you're saying is that AI is not designed to work outside of Azure - and I MUST wait for it to call the local IP in Azure environments.

[johnib]

That's not true. I use AI in AWS, it works the same as in Azure's VMs.

The endpoint they are trying to call contains additional metadata about the VM, Azure region etc.

It's not necessary.

[wictorwilen]

@johnib - gotcha, It has been working without this timeout for years for me. I do think that there should be an option to opt-out of this behaviour, as in my case I'm not tracking any VM or Azure usage.