watson-developer-cloud / node-red-node-watson

A collection of nodes for the IBM Watson services
Apache License 2.0
82 stars 86 forks source link

Conversation node hangs when "Unauthorized" exception is thrown by the conversation service #240

Closed chan71 closed 7 years ago

chan71 commented 7 years ago

We use the conversation node in our node red app that talks to conversation service. During a test, we observed that an exception had been thrown from conversation service on 16th Monday 13:00 - 15:00 IST causing conversation node to crash or hang. There was no response returned to subsequent nodes. Having validated with conversation service team through slack, it was confirmed that conversation service throws the exception but conversation node doesn't probably handle it. Error was displayed in the debug window but catch node was not able to catch it as it hangs in conversation node. Error description - "Error: Unauthorized : Access is denied due to invalid credentials"

Due to this, client app that calls the node red app hangs for ever. It is best if such error returned by conversation service are thrown to subsequent nodes.

Issue raised in stackoverflow.

chughts commented 7 years ago

The conversation node does catch the exception and reports it. If Node-RED is still running, then the node has not crashed, it has handled the exception gracefully. You see the error displayed in the debug window because the node put it there.

It doesn't propagate msg, as the service has failed to be invoked. Invalid Credentials is a configuration error and not really a runtime error. It should be detected at test of a flow. ie. if you are creating a flow, you should test it, and invalid credential type errors resolved.

chan71 commented 7 years ago

@chughts First of all, I agree that Unauthorized type of errors are due to configuration problems but those occur at runtime too. Just check what has happened for the past week in IBM Bluemix platform that triggered this error. You can see the conversation service issue we faced yesterday here.

RESOLVED: Issues with the Watson Conversation and Dialog service in all public regions The Watson Conversation and Watson Dialog services are currently experiencing issues in the US South, United Kingdom and Sydney regions.

The operations team is investigating the issue and working toward a resolution.

We apologize for the inconvenience.

Update: 2017-01-20 07:25 AM UTC: Watson Dialog Service issues have been resolved; work to resolve Watson Conversation issues continues.

Update-2: 2017-01-20 10:19 AM UTC: Watson Conversation Service issues have been resolved. Please contact technical support if you have any ongoing issues to report.

Updated: Jan 20, 2017 10:58 AM UTC+0000 Starts: Jan 20, 2017 5:15 AM UTC+0000 Ends: Jan 20, 2017 10:19 AM UTC+0000 Category: Conversation Region(s): au-syd eu-gb us-south ID: 305572

As conversation service is throwing this exception, conversation node has to handle it or re-throw it so that calling nodes can handle it. Right now, it just hangs there.

chughts commented 7 years ago

The node does handle the exception. If it did not then your instance of Node-RED would stop running with an unhandled exception. The node does not hang. It just doesn't propagate the msg flow.

chan71 commented 7 years ago

@chughts Thanks for confirming that conversation node does handle exception. We will check again what had caused the node red app to hand when "Unauthorized" exception is thrown from conversation service.

chughts commented 7 years ago

Let's try this again.

You see a perceived hang because the node does not propagate the flow, when it sees the exception. Instead it reports it, shows a red error status, and posts an error message on that the debug panel.

chan71 commented 7 years ago

@chughts That makes sense. And even if we use a catch node to handle exceptions, this is not reaching the catch node either. Wondering if there is a way to continue the flow when such exception occurs. Right now, we wait for couple of seconds for conversation service to return the response failing which we retry by calling conversation service. This is a not a great solution but it works for this issue.

chughts commented 7 years ago

Keeping this open whilst we think of ways of signalling an exception without breaking existing flows.

chughts commented 7 years ago

Implemented in 0.5.14, by applying a fix to node.error invocation.

chughts commented 7 years ago

Released.