A unique problem with Watson conversation service and node red
My Ipad app is using a Node-Red flow that has conversation embedded in the flow.
Conversation service does not re-issue a new conversation_id when the conversation is on a dialog node that has condition = true when the iPad app is restarted. Infact, anytime the app calls the flow going forward, Watson conversation will return the same conversation_id and dialog node answer regardless of the context object being present. Only after restarting the flow - fixes the problem. There is a caching problem going on somewhere outside the Watson conversation api. Watson developers claim that the service is stateless and they only act on the presence of the context object. This is not a code issue with the node red flow, I have verified that the function node constructs the proper json struct sent to the conversation api and it has been debugged dozens of time. So what is left : nodered and the nodejs container.
Json Debug Example
First send to Conversation service, without Context structure
2016-09-13T14:14:27.724-0600[App/0]OUT13 Sep 20:14:27 - [info] [function:Make String for Conversation] {"context":"","email":"dennisnoto@gmail.com","fname":"Mary","input":"Hi","lname":"Smith","nname":"Molly","phone":"720-236-2541","workspace_id":"71fb6c7d-730c-45ea-94e5-e7704b0eb4ca"}
Conversation service sent back a context block with conversation id present. As expected.
2016-09-13T14:14:27.911-0600[App/0]OUT13 Sep 20:14:27 - [info] [function:Watson Response Msg] {"text":"Howdy Mary, Can I help you with learning about investing?","username":"Watson","context":"{\"conversation_id\":\"5c1605c7-17ae-4680-8907-fc540e7bfb88\",\"system\":{\"dialog_stack\":[\"node_6_1467586704662\"],\"dialog_turn_counter\":11,\"dialog_request_counter\":11,\"system\":{\"_node_output_map\":{\"node_6_1467586704662\":[0]}}},\"fname\":\"Mary\",\"lname\":\"Smith\",\"nname\":\"Molly\",\"email\":\"dennisnoto@gmail.com\",\"phone\":\"720-236-2541\"}"}
Stopped my app and restarted at a dialog node with condition = true. Sent the start of a new conversation with no context block present.
2016-09-13T14:19:34.717-0600[App/0]OUT13 Sep 20:19:34 - [info] [function:Make String for Conversation] {"context":"","email":"dennisnoto@gmail.com","fname":"Mary","input":"Hi","lname":"Smith","nname":"Molly","phone":"720-236-2541","workspace_id":"71fb6c7d-730c-45ea-94e5-e7704b0eb4ca"}
Conversation sends back the same context block with the same conversation_id.
2016-09-13T14:19:34.877-0600[App/0]OUT13 Sep 20:19:34 - [info] [function:Watson Response Msg] {"text":"I am here at the point of no return","username":"Watson","context":"{\"conversation_id\":\"5c1605c7-17ae-4680-8907-fc540e7bfb88\",\"system\":{\"dialog_stack\":[\"node_1_1473797885279\"],\"dialog_turn_counter\":16,\"dialog_request_counter\":16,\"system\":{\"_node_output_map\":{\"node_6_1467586704662\":[0,1]}}},\"fname\":\"Mary\",\"lname\":\"Smith\",\"nname\":\"Molly\",\"email\":\"dennisnoto@gmail.com\",\"phone\":\"720-236-2541\"}"}
Re-Started flow
2016-09-13T14:19:34.876-0600[App/0]OUT13 Sep 20:19:34 - [info] [function:Watson Response Msg] ["I am here at the point of no return"]
2016-09-13T14:30:01.272-0600[App/0]OUT13 Sep 20:30:01 - [info] Stopping flows
2016-09-13T14:30:01.273-0600[App/0]OUT13 Sep 20:30:01 - [info] Starting flows
2016-09-13T14:30:01.273-0600[App/0]OUT13 Sep 20:30:01 - [info] Stopped flows
2016-09-13T14:30:01.587-0600[App/0]OUT13 Sep 20:30:01 - [info] Started flows
2016-09-13T14:30:30.950-0600[App/0]OUT13 Sep 20:30:30 - [info] [function:Make String for Conversation]
Sent first convo {"context":"","email":"dennisnoto@gmail.com","fname":"Mary","input":"Hi","lname":"Smith","nname":"Molly","phone":"720-236-2541","workspace_id":"71fb6c7d-730c-45ea-94e5-e7704b0eb4ca"} Returned new conversation_id as expected. Restarting the flow is not an option.
2016-09-13T14:30:31.168-0600[App/0]OUT13 Sep 20:30:31 - [info] [function:Watson Response Msg] {"text":"Howdy , Can I help you with learning about investing?","username":"Watson","context":"{\"conversation_id\":\"c66cb700-2917-48ff-9195-70ab4a037f04\",\"system\":{\"dialog_stack\":[\"node_6_1467586704662\"],\"dialog_turn_counter\":1,\"dialog_request_counter\":1,\"system\":{\"_node_output_map\":{\"node_6_1467586704662\":[1]}}}}"}
Have you made sure its not HTTP caching. i.e. your browser caching? Tip: Send no cache headers back with your responses.
can't be http caching. Its a rest web service call from a native ios app. Don't know if node-red has a caching issue or the nodejs that node-red runs on has a caching issue??
To null out the context object, try sending it as an null object, rather than a null string. eg.
"context":"{}",
In my flow, I construct a new message every time I send to conversation. I don't put the context object in the json object when initiating a new conversation. Not the problem. In fact this problem only happens if you bail out of the conversation on a dialog node that has condition = true. I can restart the app a 100 times, not even have the context variable passed to the service and it will still remember the conversation until I restart the bordered flow!!! Weird huh? Not a flow coding problem. its something outside my control.
As per my previous comment, have you tried to bail out of the conversation by sending in a null context object and not a null string as you have in your examples?
eg. "context":"{}",
So dude, you know something. So by sending the context = {} it worked!!! But why does not sending context at all screw up the service??
Don't know, as the node does the same thing set context = {}, if no context is passed in.
We are reworking the conversation node to be able to remember context. Default mode will be as is, where it doesn't remember context, so you will need to pass it in. Single User mode will remember the context, you will not need to pass it in. Multiple User mode will also remember the context. You will not need to pass in the context, but you will need to pass in an id, that you set and remember. You will be able to add variables to the context. Reset of context will be by setting context = {}
When will this be available? Thanks!
I see "save context" and "multiple user" check boxes on the WCS service in node-red and their is a new msg.user property. I tried looking this up on the api documentation, no luck. Where are the docs on what these changes actually dol.