I have faced an issue with AIML conversation, I am using multiple AIML files in chatbot but whenever I start the conversation with the chatbot it is showing “No AIML category found.This is a Default Response" initially, and if I continue the same question again it gives a proper response.
ex:
User: Hi
bot: No AIML category found. This is a Default Response.
User: Hi
bot: Hello
I’ve checked the conversation log of program-o and attached the image
But here it will respond properly when sending the same message again.
I can't see this in my unknown inputs log in program-o,
And then I got these from my debug log
“30-04-2018 05:14:48.76763[4][4] - Elapsed time: 0.020 milliseconds
[load_userfunctions.php][Called outside of function][14]
userfunctions include files loaded “
And these lines are written in error log
04/30/2018 05:14:41 - PHP ERROR [Notice] -Undefined index: srai_input in >/var/www/html/chatbot/core/aiml/parse_aiml.php on Line 297”
I am facing these issues in my all program-o bots
Related
In ECS Fargate, when a task fails, there is a "Stopped Reason" field which gives some useful logging. However I have noticed that it gets truncated after 255 symbols (screenshot below).
I checked the network tab and tracked the JSON of the http response, and it is truncated even there (so server-side). Is there any way to get the complete message?
I find this thread where they discuss the same problem.
How can I see the whole, untruncated error message?
I found the whole error message in CloudTrail eventually. I searched by "Username", and entered the Task GUID as username. This narrowed down the amount of events I had to sift through. The full error message was in a "GetParameters" event.
Just FYI for anyone who reads this answer the task GUID is the ID at the end of the taskArn or if you go to Task in the console it will be the ID that you see in Task : fc0398a94d8b4d4d9218a6d870914a80 –
Emmanuel N K
Jun 21 at 13:21
So, I just started with Rasa this week, but I’m quite happy with the results so far, as in that it responds well et cetera. However, I now have custom actions in an actions.py file, but when I’m in the rasa shell it seems to miss that file entirely and asks for another input. (see the image below) It doesn't even give an error. What am I doing wrong?
I tried to run "rasa run actions" in another terminal, with an action_endpoint in the endpoints.yml file.
In the endpoints file:
`action_endpoint:
url: "http://localhost:5055/webhook"`
This is the part I'm running in the separate terminal:
`(actions) C:\.potato>python -m rasa_sdk --actions actions
2019-07-11 10:29:16 INFO rasa_sdk.endpoint - Starting action endpoint server...
2019-07-11 10:29:17 INFO rasa_sdk.executor - Registered function for 'action_validate_cuisine'.
2019-07-11 10:29:17 INFO rasa_sdk.executor - Registered function for 'action_search_restaurants'.
2019-07-11 10:29:17 INFO rasa_sdk.endpoint - Action endpoint is up and running. on ('0.0.0.0', 5055)`
This is the output in the other terminal:
`(cozmobot) C:\.potato>rasa shell
2019-07-11 10:49:36 INFO root - Starting Rasa Core server on http://localhost:5005
Bot loaded. Type a message and press enter (use '/stop' to exit):
Your input -> Hi!
Hey! What's up?
Your input -> I'm hungry
What kind of restaurant would you like?
Your input -> I would like italian
Your input -> <HERE AN ANSWER SHOULD BE GIVEN BY THE BOT VIA ACTIONS.PY>
Your input -> /stop
2019-07-11 10:50:19 INFO root - Killing Sanic server now.`
The third input should be answered by the bot with a correct restaurant. But for some reason it does not go there, without giving an error, and just asks for another input of the user.
You need to add the --endpoints flag to the command, i.e. run
rasa shell --endpoints endpoints.yml
I have a speech project which uses web service. I have set the timeout for 45 seconds in OD but when I deploy it, I get the following error for the first calling user in EP log viewer:
Fetch time out when opening timed stream for url =
http://example.com/AppName/SetLanguage?___DDSESSIONID=EF3397385F3E9BC0E89D526B3FCB811A%3A%2FAppName.
Timeout was = 15000
Session=ccmpp03-2018026140450-10
I think, EP has some default timeout of 15 sec.
1)Is there a way to increase it?
2)Is there any other solutions for this problem?
You should check this:
How to change the default Avaya Voice Browser (AVB) timeout value from an Avaya Voice Portal system?
you can change fetch time in AEP that is for all the application configured in AEP. if you want to change the fetch time for single speech application you need to add a property in the root then configured the fetch time for individual speech application.
enter image description here
enter image description here
I have an AWS API Gateway setup, served by a Python Lambda function. For successful responses the Lambda returns a response of the form:
"200:{\"somekey\": \"somevalue\"}"
By default, the Integration Response settings in the gateway console have just one rule configured with a Lambda Error Regex of .* mapping to a response status of 200. This works fine.
The problem is when I try to change that to 200.* (with a view to enabling more specific codes going forward). Now I get a
{"message": "Internal server error"}
every time I hit the gateway with any request (resulting in a 200 or not).
No error logs are written to CloudWatch.
I want to know how I can map Lambda outputs to HTTP status codes successfully in AWS API Gateway.
If you do a test run in API gateway, the test run log should show an error similar to:
Sat Nov 21 07:41:25 UTC 2015 : Execution failed due to configuration
error: No match for output mapping and no default output mapping
configured
The problem is there is no-longer a default mapping to catch a successful response. The intention of the error regex is to catch errors and map them to status codes. The error regex searches the errorMessage property of the failed json response. If you were to set the status code 400 to be the default (blank) - you would find your successful response always mapping to a status code of 400.
You'll be best off to leave 200 as a default (blank) regex. Then set specific regex values to check for your different error messages. For example, you can have multiple specific error regex status codes and a generic catch-all to result in 500's.
For those who tried everything put on this question and couldn't make this work (like me), check the thedevkit comment on this post (saved my day):
https://forums.aws.amazon.com/thread.jspa?threadID=192918
Reproducing it entirely below:
I've had issues with this myself, and I believe that the newline
characters are the culprit.
foo.* will match occurrences of "foo" followed by any characters
EXCEPT newline. Typically this is solved by adding the '/s' flag, i.e.
"foo.*/s", but the Lambda error regex doesn't seem to respect this.
As an alternative you can use something like: foo(.|\n)*
In our Symfony2 application we query an external API for a certain service we provide. This API (let's call it Acme API) sometimes throws error messages that we forward to Graylog2 via Monolog and Gelf to keep track of outages. Every error is logged on error level with $logger->err().
The messages are shown in the normal message pool, but the custom stream that collects these API error messages isn't showing any message at all.
So my main question is: Why is Graylog refusing to show messages in the stream and what can we do to change that behaviour?
Configurations
There is a total of 35 streams at the moment (This because we have a bunch of applications on our servers).
Every message that is given to Monolog has the same pattern:
Acme API Error on "{user action}": {error description}. Additional information: "{more information provided from the API}" on server "{web server name}" and domain "{domain}" for user "{session ID}"
The Graylog stream rules are as follows:
Host (regex): ^((?!mycompany-staging).)*$ // Needed to show only logs from the live servers
Facility: app
Full Message (regex): Acme API.*
(We've also tried to set the Full Message regex to .*Acme API.* and Acme API Error.*, but none of these worked)
The monolog configuration is as follows:
// config_prod.yml
// ...
monolog:
handlers:
main:
type: fingers_crossed
action_level: error
handler: nested
level: debug
nested:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
graylog:
type: gelf
level: warning
publisher:
hostname: mycompany-monitoring.mycompany.ch
// ...
Seemed to be a problem with Graylog2 itself, the stream started working normally after updating Graylog to the newest version and recreating the stream.