Increase in UND_ERR_HEADERS_TIMEOUT errors

[mosnicholas]

What is the current behavior?

In periods of high load, response times fluctuate. If they go over 5' mark, the fetch library implemented fails, because it cannot stay alive for longer than 5'. Those timeouts are also not configurable.

This is a known limitation of the fetch library implemented.

Steps to reproduce

It's ad-hoc and depends on response rates & usage of Deepgram's servers

Expected behavior

That we don't see timeout issues and can configure timeout values if needed.

Please tell us about your environment

• Operating System/Version: Mac
• Language: [TypeScript]
• Browser: Chrome

This is from calls made server side

Other information

[jjmaldonis]

Dropping thoughts from an internal convo:

Below are the workarounds:

1. Create a server to receive asynchronous requests via a callback URL.
   1. This is DG's recommended approach because you'll have a more robust system that is less sensitive to issues like these.
   2. But it requires significant engineering work to get up and running, and changes to your code are required.
2. Downgrade to the JS SDK v2.
   1. We don't recommend this because the v2 SDK will have limited supported going forward. For example, DG's new Speech Intelligence and TTS features will not be supported.
   2. This is a smaller engineering effort and will likely resolve the 5 minute maximum timeout.
3. 1. Patch the v3 SDK and submit a PR so DG can merge it and give you the functionality you want.
   2. This would be awesome! We'd love a contribution.
   3. But it's more engineering effort for you.
4. Wait for DG to update the v3 SDK.
   1. Currently this isn't at the top of our priority list, but if other projects go smoothly we could get it done.
   2. But you have to wait to get the improvement.

This is what we've found out about the issue, and these are the constraints involved:

• The v3 SDK has support for both the browser and server implementations. The v2 SDK only supported servers (not the browser!). This is a major improvement to the v3 SDK because it facilitates an entirely new use case for the JS SDK.
• fetch is implemented differently by the browser vs. Node (ie the server).
  • The browser's fetch implementation has a non-configurable timeout that is set by the browser.
    • "In Chrome a network request timeouts at 300 seconds, while in Firefox at 90 seconds. 300 seconds and even 90 seconds are way more than a user would expect a network request to complete." -- says google
  • Node has multiple implementations of fetch. Currently, the v3 SDK uses Node's default implementation of fetch, which has a non-configurable 5 minute max timeout.
    • There is a different, non-default implementation of fetch for Node that allows users to configure the max timeout. This is what needs to be implemented in the JS SDK.
• The v3 SDK has a resolveFetch method that can probably be updated to configure which version of Node's fetch is used.
• We aren't 100% sure what's involved to get this implemented, so it'll take some digging in to understand where the configuration options need to go, or how the user can override/configure/polyfill Node's fetch to use the time-configurable version of fetch

[lukeocodes]

the solution #245 has now provided the ability to override fetch with a custom fetch interface