How to fallback into error when reprompt is processed in Alexa Skill
I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:
When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?
I've upload a demo project to emulate this behaviour
You can try with this the workflow:
- Start the Skill
- The skill returns the "Number One" text and stays listening (as there's a reprompt)
- You write number two
- The skill returns the "Number Two" text and stays listening with another reprompt
- You say gibberish, for example, "d" or "blah blah blah"
- You are sorted on a apparently random utterance.
Here's an example of the JSON input for "blah blah blah"
{
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
},
"device": {
"deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.eu.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
},
"Viewport": {
"experiences": [
{
"arcMinuteWidth": 246,
"arcMinuteHeight": 144,
"canRotate": false,
"canResize": false
}
],
"shape": "RECTANGLE",
"pixelWidth": 1024,
"pixelHeight": 600,
"dpi": 160,
"currentPixelWidth": 1024,
"currentPixelHeight": 600,
"touch": [
"SINGLE"
]
}
},
"request": {
"type": "IntentRequest",
"requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
"timestamp": "2018-11-16T08:17:34Z",
"locale": "es-ES",
"intent": {
"name": "NumberTwoIntent",
"confirmationStatus": "NONE"
}
}
}
How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.
Thank you
alexa alexa-skills-kit alexa-skill
add a comment |
I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:
When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?
I've upload a demo project to emulate this behaviour
You can try with this the workflow:
- Start the Skill
- The skill returns the "Number One" text and stays listening (as there's a reprompt)
- You write number two
- The skill returns the "Number Two" text and stays listening with another reprompt
- You say gibberish, for example, "d" or "blah blah blah"
- You are sorted on a apparently random utterance.
Here's an example of the JSON input for "blah blah blah"
{
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
},
"device": {
"deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.eu.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
},
"Viewport": {
"experiences": [
{
"arcMinuteWidth": 246,
"arcMinuteHeight": 144,
"canRotate": false,
"canResize": false
}
],
"shape": "RECTANGLE",
"pixelWidth": 1024,
"pixelHeight": 600,
"dpi": 160,
"currentPixelWidth": 1024,
"currentPixelHeight": 600,
"touch": [
"SINGLE"
]
}
},
"request": {
"type": "IntentRequest",
"requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
"timestamp": "2018-11-16T08:17:34Z",
"locale": "es-ES",
"intent": {
"name": "NumberTwoIntent",
"confirmationStatus": "NONE"
}
}
}
How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.
Thank you
alexa alexa-skills-kit alexa-skill
add a comment |
I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:
When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?
I've upload a demo project to emulate this behaviour
You can try with this the workflow:
- Start the Skill
- The skill returns the "Number One" text and stays listening (as there's a reprompt)
- You write number two
- The skill returns the "Number Two" text and stays listening with another reprompt
- You say gibberish, for example, "d" or "blah blah blah"
- You are sorted on a apparently random utterance.
Here's an example of the JSON input for "blah blah blah"
{
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
},
"device": {
"deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.eu.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
},
"Viewport": {
"experiences": [
{
"arcMinuteWidth": 246,
"arcMinuteHeight": 144,
"canRotate": false,
"canResize": false
}
],
"shape": "RECTANGLE",
"pixelWidth": 1024,
"pixelHeight": 600,
"dpi": 160,
"currentPixelWidth": 1024,
"currentPixelHeight": 600,
"touch": [
"SINGLE"
]
}
},
"request": {
"type": "IntentRequest",
"requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
"timestamp": "2018-11-16T08:17:34Z",
"locale": "es-ES",
"intent": {
"name": "NumberTwoIntent",
"confirmationStatus": "NONE"
}
}
}
How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.
Thank you
alexa alexa-skills-kit alexa-skill
I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:
When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?
I've upload a demo project to emulate this behaviour
You can try with this the workflow:
- Start the Skill
- The skill returns the "Number One" text and stays listening (as there's a reprompt)
- You write number two
- The skill returns the "Number Two" text and stays listening with another reprompt
- You say gibberish, for example, "d" or "blah blah blah"
- You are sorted on a apparently random utterance.
Here's an example of the JSON input for "blah blah blah"
{
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
},
"user": {
"userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
},
"device": {
"deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.eu.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
},
"Viewport": {
"experiences": [
{
"arcMinuteWidth": 246,
"arcMinuteHeight": 144,
"canRotate": false,
"canResize": false
}
],
"shape": "RECTANGLE",
"pixelWidth": 1024,
"pixelHeight": 600,
"dpi": 160,
"currentPixelWidth": 1024,
"currentPixelHeight": 600,
"touch": [
"SINGLE"
]
}
},
"request": {
"type": "IntentRequest",
"requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
"timestamp": "2018-11-16T08:17:34Z",
"locale": "es-ES",
"intent": {
"name": "NumberTwoIntent",
"confirmationStatus": "NONE"
}
}
}
How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.
Thank you
alexa alexa-skills-kit alexa-skill
alexa alexa-skills-kit alexa-skill
edited Nov 16 '18 at 12:01
Kerberos
2,61222344
2,61222344
asked Nov 16 '18 at 8:19
RodrigoRodrigo
308218
308218
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.
So overall the recommendation is to:
Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent
Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)
If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails
Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this
You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it
Do not rely on catch all handlers (
canHandle()
set to always return true) to help you with this. Some examples use anUnhandledIntentHandler
and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's noFallbackIntent
. Similarly, do not rely on anErrorHandler
added viaaddErrorHandlers()
as it will only trigger is there's an actual error in the code which is not inside a try/catch
As soon as Amazon.FallbackIntent
becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them
add a comment |
Since there is no AMAZON.FallbackIntent
Alexa always tries to map it to the closest intent.
ErrorHandler
is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers
) that can fulfil the request. Do not get confused between ErrorHandlers
and UnhandledIntentHandlers
. ErrorHandlers
are for handling errors and UnhandledIntentHandler
are/should be an IntentHandler
for handling unhandled intents.
In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler
is never called.
Since AMAZON.Fallback
cannot be used, try these:
1. Validating slots:
Consider the following utterance:
[BuyProductIntent]
Utterances:
I want a large pizza
give me a large pizza
which can be changed to
I want a {size} {product}
give me a {size} {product}
where
size-> regular, medium, large
product->pizza, burger
Now whenever your backend receives an BuyProductIntent
request, validate the slots and respond with appropriate message. If some how BuyProductIntent
is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.
"Sorry, I didn't understand. Do you want to order pizza"
This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.
2. Add an OutOfDomainIntent
Create an OutOfDomainIntent
and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.
1
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
2
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message"message":"Could not find handler that can handle the request"
and"name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I describedErrorHandler
looked more like anUnhandledIntentHandler
. Thanks for pointing it out, I will update.
– Cicil Thomas
Nov 18 '18 at 6:53
1
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
1
@German I have updated my answer. So unhandled intents should not be handled by anErrorHandler
, instead they should be handled by anIntentHandler
itself. Thanks for the info.
– Cicil Thomas
Nov 18 '18 at 16:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333910%2fhow-to-fallback-into-error-when-reprompt-is-processed-in-alexa-skill%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.
So overall the recommendation is to:
Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent
Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)
If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails
Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this
You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it
Do not rely on catch all handlers (
canHandle()
set to always return true) to help you with this. Some examples use anUnhandledIntentHandler
and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's noFallbackIntent
. Similarly, do not rely on anErrorHandler
added viaaddErrorHandlers()
as it will only trigger is there's an actual error in the code which is not inside a try/catch
As soon as Amazon.FallbackIntent
becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them
add a comment |
The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.
So overall the recommendation is to:
Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent
Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)
If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails
Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this
You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it
Do not rely on catch all handlers (
canHandle()
set to always return true) to help you with this. Some examples use anUnhandledIntentHandler
and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's noFallbackIntent
. Similarly, do not rely on anErrorHandler
added viaaddErrorHandlers()
as it will only trigger is there's an actual error in the code which is not inside a try/catch
As soon as Amazon.FallbackIntent
becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them
add a comment |
The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.
So overall the recommendation is to:
Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent
Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)
If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails
Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this
You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it
Do not rely on catch all handlers (
canHandle()
set to always return true) to help you with this. Some examples use anUnhandledIntentHandler
and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's noFallbackIntent
. Similarly, do not rely on anErrorHandler
added viaaddErrorHandlers()
as it will only trigger is there's an actual error in the code which is not inside a try/catch
As soon as Amazon.FallbackIntent
becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them
The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.
So overall the recommendation is to:
Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent
Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)
If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails
Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this
You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it
Do not rely on catch all handlers (
canHandle()
set to always return true) to help you with this. Some examples use anUnhandledIntentHandler
and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's noFallbackIntent
. Similarly, do not rely on anErrorHandler
added viaaddErrorHandlers()
as it will only trigger is there's an actual error in the code which is not inside a try/catch
As soon as Amazon.FallbackIntent
becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them
edited Jan 10 at 9:45
answered Nov 17 '18 at 23:51
GermanGerman
7,23642746
7,23642746
add a comment |
add a comment |
Since there is no AMAZON.FallbackIntent
Alexa always tries to map it to the closest intent.
ErrorHandler
is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers
) that can fulfil the request. Do not get confused between ErrorHandlers
and UnhandledIntentHandlers
. ErrorHandlers
are for handling errors and UnhandledIntentHandler
are/should be an IntentHandler
for handling unhandled intents.
In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler
is never called.
Since AMAZON.Fallback
cannot be used, try these:
1. Validating slots:
Consider the following utterance:
[BuyProductIntent]
Utterances:
I want a large pizza
give me a large pizza
which can be changed to
I want a {size} {product}
give me a {size} {product}
where
size-> regular, medium, large
product->pizza, burger
Now whenever your backend receives an BuyProductIntent
request, validate the slots and respond with appropriate message. If some how BuyProductIntent
is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.
"Sorry, I didn't understand. Do you want to order pizza"
This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.
2. Add an OutOfDomainIntent
Create an OutOfDomainIntent
and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.
1
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
2
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message"message":"Could not find handler that can handle the request"
and"name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I describedErrorHandler
looked more like anUnhandledIntentHandler
. Thanks for pointing it out, I will update.
– Cicil Thomas
Nov 18 '18 at 6:53
1
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
1
@German I have updated my answer. So unhandled intents should not be handled by anErrorHandler
, instead they should be handled by anIntentHandler
itself. Thanks for the info.
– Cicil Thomas
Nov 18 '18 at 16:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
add a comment |
Since there is no AMAZON.FallbackIntent
Alexa always tries to map it to the closest intent.
ErrorHandler
is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers
) that can fulfil the request. Do not get confused between ErrorHandlers
and UnhandledIntentHandlers
. ErrorHandlers
are for handling errors and UnhandledIntentHandler
are/should be an IntentHandler
for handling unhandled intents.
In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler
is never called.
Since AMAZON.Fallback
cannot be used, try these:
1. Validating slots:
Consider the following utterance:
[BuyProductIntent]
Utterances:
I want a large pizza
give me a large pizza
which can be changed to
I want a {size} {product}
give me a {size} {product}
where
size-> regular, medium, large
product->pizza, burger
Now whenever your backend receives an BuyProductIntent
request, validate the slots and respond with appropriate message. If some how BuyProductIntent
is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.
"Sorry, I didn't understand. Do you want to order pizza"
This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.
2. Add an OutOfDomainIntent
Create an OutOfDomainIntent
and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.
1
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
2
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message"message":"Could not find handler that can handle the request"
and"name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I describedErrorHandler
looked more like anUnhandledIntentHandler
. Thanks for pointing it out, I will update.
– Cicil Thomas
Nov 18 '18 at 6:53
1
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
1
@German I have updated my answer. So unhandled intents should not be handled by anErrorHandler
, instead they should be handled by anIntentHandler
itself. Thanks for the info.
– Cicil Thomas
Nov 18 '18 at 16:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
add a comment |
Since there is no AMAZON.FallbackIntent
Alexa always tries to map it to the closest intent.
ErrorHandler
is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers
) that can fulfil the request. Do not get confused between ErrorHandlers
and UnhandledIntentHandlers
. ErrorHandlers
are for handling errors and UnhandledIntentHandler
are/should be an IntentHandler
for handling unhandled intents.
In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler
is never called.
Since AMAZON.Fallback
cannot be used, try these:
1. Validating slots:
Consider the following utterance:
[BuyProductIntent]
Utterances:
I want a large pizza
give me a large pizza
which can be changed to
I want a {size} {product}
give me a {size} {product}
where
size-> regular, medium, large
product->pizza, burger
Now whenever your backend receives an BuyProductIntent
request, validate the slots and respond with appropriate message. If some how BuyProductIntent
is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.
"Sorry, I didn't understand. Do you want to order pizza"
This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.
2. Add an OutOfDomainIntent
Create an OutOfDomainIntent
and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.
Since there is no AMAZON.FallbackIntent
Alexa always tries to map it to the closest intent.
ErrorHandler
is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers
) that can fulfil the request. Do not get confused between ErrorHandlers
and UnhandledIntentHandlers
. ErrorHandlers
are for handling errors and UnhandledIntentHandler
are/should be an IntentHandler
for handling unhandled intents.
In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler
is never called.
Since AMAZON.Fallback
cannot be used, try these:
1. Validating slots:
Consider the following utterance:
[BuyProductIntent]
Utterances:
I want a large pizza
give me a large pizza
which can be changed to
I want a {size} {product}
give me a {size} {product}
where
size-> regular, medium, large
product->pizza, burger
Now whenever your backend receives an BuyProductIntent
request, validate the slots and respond with appropriate message. If some how BuyProductIntent
is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.
"Sorry, I didn't understand. Do you want to order pizza"
This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.
2. Add an OutOfDomainIntent
Create an OutOfDomainIntent
and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.
edited Nov 18 '18 at 16:48
answered Nov 16 '18 at 12:47
Cicil ThomasCicil Thomas
3,18521431
3,18521431
1
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
2
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message"message":"Could not find handler that can handle the request"
and"name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I describedErrorHandler
looked more like anUnhandledIntentHandler
. Thanks for pointing it out, I will update.
– Cicil Thomas
Nov 18 '18 at 6:53
1
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
1
@German I have updated my answer. So unhandled intents should not be handled by anErrorHandler
, instead they should be handled by anIntentHandler
itself. Thanks for the info.
– Cicil Thomas
Nov 18 '18 at 16:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
add a comment |
1
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
2
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message"message":"Could not find handler that can handle the request"
and"name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I describedErrorHandler
looked more like anUnhandledIntentHandler
. Thanks for pointing it out, I will update.
– Cicil Thomas
Nov 18 '18 at 6:53
1
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
1
@German I have updated my answer. So unhandled intents should not be handled by anErrorHandler
, instead they should be handled by anIntentHandler
itself. Thanks for the info.
– Cicil Thomas
Nov 18 '18 at 16:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
1
1
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
Cicil this answer is pretty good but there's one mistake with regards to what you say about ErrorHandler. The ErrorHandler, usually added via addErrorHandlers(), will not trigger when there are no more handlers that can fulfill the request, it will trigger when an error is thrown in the code (an not inside a try/catch). What you're describing sounds more like an UnhandledIntentHandler with the canHandle() set to return true. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent.
– German
Nov 17 '18 at 23:01
2
2
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message
"message":"Could not find handler that can handle the request"
and "name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I described ErrorHandler
looked more like an UnhandledIntentHandler
. Thanks for pointing it out, I will update.– Cicil Thomas
Nov 18 '18 at 6:53
@German I double checked. If there are no intent handlers that can handle a request, an error handler capable of handling it will be triggered with an error message
"message":"Could not find handler that can handle the request"
and "name":"AskSdk.DefaultRequestDispatcher Error"
. As you said, the way I described ErrorHandler
looked more like an UnhandledIntentHandler
. Thanks for pointing it out, I will update.– Cicil Thomas
Nov 18 '18 at 6:53
1
1
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
Cicl: that happens indirectly, I believe it's a RequestChain not found error. So, yes, the ErrorHandler will be triggered but I would not rely on this to detect an unhandled intent, it's very indirect (it's collateral damage). Thanks for your great help in Stackoverflow regarding Alexa, it's excellent
– German
Nov 18 '18 at 16:08
1
1
@German I have updated my answer. So unhandled intents should not be handled by an
ErrorHandler
, instead they should be handled by an IntentHandler
itself. Thanks for the info.– Cicil Thomas
Nov 18 '18 at 16:58
@German I have updated my answer. So unhandled intents should not be handled by an
ErrorHandler
, instead they should be handled by an IntentHandler
itself. Thanks for the info.– Cicil Thomas
Nov 18 '18 at 16:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
That's exactly right Cicil, thx again
– German
Nov 18 '18 at 19:58
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333910%2fhow-to-fallback-into-error-when-reprompt-is-processed-in-alexa-skill%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown