I am creating agent using dialogflow with webhook. Facing problem in webhook timeout:
webhook_status { code: 4 message: "Webhook call failed. Error: Request
timeout." }
kindly help me to increase webhook timeout time.
There is no way you can increase Time Out for webhook. Your webhook should respond back within 5 seconds (see Limits here)
Related
I'm new to Spring Integration. I have a simple flow which send request to external resource with several attemps.
IntegrationFlows.from(MY_CHANNEL)
.handle(myOutboundGateway, e -> e.advice(myRetryAdvice))
.wireTap(logResponse())
.get();
What I need to do is to take some action (saving data to a database) when calling external resource (after retrying) is not succesful (http status code is not 200 OK). How can I achieve that in my flow?
When all the attempts of the retry are exhausted, the RecoveryCallback is called.
See some sample here: How to get HTTP status in advice recovery callback. In that RecoveryCallback you can just return null and send a message to some channel for that storing to DB logic.
Another way is to have extra advice on top of that retry instead of RecoveryCallback. See its docs: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#expression-advice. This way when all the attempts are done, the exception is going to be bubbled and caught by that ExpressionEvaluatingRequestHandlerAdvice and its failureChannel. Pay attention to the trapException = true, so the error doesn't go back to the flow. Only to that failureChannel for your DB logic.
After few transaction while using Dialogflow APIs, DEADLINE_EXCEEDED: Deadline Exceeded error is coming and after that I always need to restart the service, then again it starts working for a while. Not getting any relevant answers even after trying lots of blogs.
Using node package: dialogflow
and dialogflow standard edition (Free Version)
Tried with various agent of Dialogflow, but not getting the response.
Error: 4 DEADLINE_EXCEEDED: Deadline Exceeded
at Object.exports.createStatusError (/srv/node_modules/grpc/src/common.js:87:15)
at Object.onReceiveStatus (/srv/node_modules/grpc/src/client_interceptors.js:1188:28)
at InterceptingListener._callNext (/srv/node_modules/grpc/src/client_interceptors.js:564:42)
at InterceptingListener.onReceiveStatus (/srv/node_modules/grpc/src/client_interceptors.js:614:8)
at callback (/srv/node_modules/grpc/src/client_interceptors.js:841:24)
code: 4,
metadata: Metadata { _internal_repr: {} },
details: 'Deadline Exceeded' }
While using dialogflow node package, and here using
const sessionClient = new dialogflow.SessionsClient();
to detect intent not getting the result as detected intent after hitting query for a phrase.
The DEADLINE_EXCEEDED error is triggered when the webhook call exceeds the maximum wait time.
As stated on DialogFlow fulfillment documentation:
The response must occur within 10 seconds for Actions on Google
applications or 5 seconds for all other applications, otherwise the
request will time out.
If you want, on dialogflow, you can set a pre-defined message that is sent when the fulfillment request exceeds the available time.
I'm sending messages via the Gmail API. In particular, I am trying to send 5-7 emails from the same account to different users (1 each) within about 2 seconds.
About 8% of those emails are failing with this error:
&googleapi.Error{
Code:500,
Message:"Backend Error", Body:`{
"error": {
"errors": [
{
"domain": "global",
"reason": "backendError",
"message": "Backend Error"
}
],
"code": 500,
"message": "Backend Error"
}
}`,
Header:http.Header(nil),
Errors:[]googleapi.ErrorItem{
googleapi.ErrorItem{Reason:"backendError", Message:"Backend Error"}
}
}
It doesn't seem like it's specific to a particular account, as 6/7 emails may succeed.
I'm hesitant to retry this for fear of sending 2 emails to the same person.
Is there any way to tell whether this message is safe to retry?
"code": 500, "message": "Backend Error"
Is basically an issue with Google server. Either the request you are making took to long or the server preforming the request is busy and the request again took to long. It doesn't sound like what you are doing should be causing the problem.
Tips when not to run: Don't run on the hour you will be completing with everyone who has cron jobs set up also don't run at midnight (PDT) as this is when quotas reset and again you will be completing with everyone who blew out yesterdays quota.
Solution:
The normal solution is to wait a few seconds then send the same request again. (Implementing Exponential Backoff)
The flow for implementing simple exponential backoff is as follows.
Make a request to the API
Receive an error response that has a retry-able error code
Wait 1s + random_number_milliseconds seconds
Retry request
Receive an error response that has a retry-able error code
Wait 2s + random_number_milliseconds seconds
Retry request
Receive an error response that has a retry-able error code
Wait 4s + random_number_milliseconds seconds
Retry request
Receive an error response that has a retry-able error code
Wait 8s + random_number_milliseconds seconds
Retry request
Receive an error response that has a retry-able error code
Wait 16s + random_number_milliseconds seconds
Retry request
If you still get an error, stop and log the error.
Sometimes it can happen before send and sometimes after send.
I logged the "To" and "From" from five different email attempts that all received a 500 Backend Error. None of these attempts made it to the "Sent" folder of my inbox. I conclude that they were never sent, and it's safe to retry these messages. However, other people in the comments (see below) indicated that the messages actually made it to the remote mailbox, and it's not safe to retry.
I have received the following error when trying to save a DSX Scheduled Job:
Job schedule entry could not be created. Status code: 500
Screenshot of the error message:
I've tried about six times over the last few hours and have consistently received the above error message.
Debugging via the browser network inspection tool I can see:
{
"code":"CDSX.N.1001",
"message":"The service is not responding, try again later.",
"description":"",
"httpMethod":"POST",
"url":"https://batch-schedule-prod.spark.bluemix.net:12100/schedules",
"qs":"",
"body":"While attempting to get Bluemix Token from BlueIDToken, unable to retrieve AccessToken, failed with status 400 Bad Request, message = {\"error\":\"invalid_grant\",\"error_description\":\"A redirect_uri can only be used by implicit or authorization_code grant types.\"} Entity: {\"error\":\"invalid_grant\",\"error_description\":\"A redirect_uri can only be used by implicit or authorization_code grant types.\"}",
"statusCode":500,
"duration":666,
"expectedStatusCode":201
}
As per Charles comment, the functionality is working ok now. I guess if this happens to another user some time in the future they should contact support.
We're using an http inbound gateway to process http requests. Lately , we wanted to set specific http response code that will be sent to user after a timeout.
We upgraded to spring 4.2.1 and set
the reply-timeout-status-code-expression attribute
and it's working now.
But there is a problem : if we set the timeout to 10 seconds , a ReplyTimeoutException is raised in the web application after exactly 10 seconds but the response arrives to the client after 20 seconds ( exactly the double ).
We changed the timeout several times but it always take 2x timeout for the response to be received by client.
This is the xml config for the http inbound gateway :
<int-http:inbound-gateway id="inboundRequest" request-channel="inbound-channel"
supported-methods="POST" path="/Request" error-channel="errorChannel" reply-channel="gateway_response"
reply-timeout="5000" request-payload-type="java.lang.String" reply-timeout-status-code-expression="'504'" >
A Help would be really appreciated
I see you have an error-channel - if the error flow returns no response, the reply timer starts again when the error flow ends (we're waiting for a reply from the error flow).
Instead of returning nothing from the error flow, you need to throw a MessageTimeoutException.
Turning on DEBUG logging and following the message flow is the best way to diagnose issues like this.
If that's not the problem, you need to show the rest of your configuration (edit the question, don't try to post it in a comment).