How to deal with unhandled rejection connect ETIMEDOUT?

[ujja]

We got a timeout on prod env:

Got an unhandledRejection FetchError: request to https://global-dialogflow.googleapis.com/$rpc/google.cloud.dialogflow.cx.v3.Sessions/DetectIntent failed, reason: connect ETIMEDOUT xxx

My initial thought was, that the customer using some (randomly) slow external lib. It looked a good decision to just increase the timeout.

But I realized that the timeout for this call is 22 000ms. And we got the exception after 2s maybe (im not sure, its hard to collect info about this problem on prod).

I played with the timeout arg, i set it to 1s on my local env:

this.sessionClient.detectIntent(request, { timeout: 1 })

But I dont see any change, it was executed without timeout errot. (on local env I dont get timeout error, but on decreasing it, i was expecting to get it)

It looks to me, that neither 22000ms, nor my value is used.

I see my timeout in createApiCall.js, thisSettings
currentApiCaller.call(apiCall, request, thisSettings, ongoingCall)

but normalApiCaller.js ignores it.:
call(apiCall, argument, settings, canceller) { canceller.call(apiCall, argument); }

maybe retry settings, and timeout settings are excluding each other? createApiCall.js:

       if (!streaming &&
            retry &&
            retry.retryCodes &&
            retry.retryCodes.length > 0) {
            retry.backoffSettings.initialRpcTimeoutMillis =
                retry.backoffSettings.initialRpcTimeoutMillis ||
                    thisSettings.timeout;
            return retries_1.retryable(func, thisSettings.retry, thisSettings.otherArgs, thisSettings.apiName);
        }
        return timeout_1.addTimeoutArg(func, thisSettings.timeout, thisSettings.otherArgs);

How can I deal with this ETIMEDOUT?
This unhandled rejection is very disturbing. We cant handle it on the correct way, it kills our process. (I already rised an issue for dialogflow cx client lib, but I suppose it is coming from gax, or grpc modules.)

[alexander-fenster]

So first of all, the unhandled rejection is a bug. I'm working right now on finding places where the exception is not caught properly, and fixing it.

Next, from what I see in the URL, you are using fallback: true. I'm afraid we don't really support timeouts for this mode (we could, should not be hard to add it, we just did not implement it yet). Is there a specific reason why are you going for the fallback implementation and not gRPC?

[ujja]

Code is not mine, I will try turn of fallback mode then.

Thank you!