How is it that the documented intent states in Lex are different from the actual available values?What is the difference between each of these states? - aws-lambda

I am currently working on integrating aws Lex with lambda function written in TypeScript and I am facing a situation in which I need help .
Upon reading the aws documentation for LexV2 the following values are available for an intent state:
Failed
Fulfilled
FulfillmentInProgress
InProgress
ReadyForFulfillment
Waiting
However when I used the 'Waiting' value, The following error message showed up :
Invalid Lambda Response: Received invalid response from Lambda: Can not deserialize value of type Intent$IntentState from String "Waiting": value not one of declared Enum instance names: [ReadyForFulfillment, InProgress, Failed, Fulfilled]
Upon this I need help to:
Understand how is it possible to have values that are not recognized.
Understand the difference between each of these values (Note: not all of the accepted values are explained in the documentation)

After reaching out to aws support here is the answer:
LexV2 doesn't accept "FulfillmentInProgress" or "Waiting" as valid intent state.
Difference between each of the valid value:
ReadyForFulfillment - The bot is ready to fulfillment. Passing this state via lambda output will make the bot jump to fulfillment state
InProgress - The default state
Fulfilled - The bot will jump to closed state and will play back both the fulfillment success message and closing response
Failed - Mark the intent as failed; will result in bot playing the
fulfillment failure message

Related

discord.py - checking if channel id is correct

In Discord.py I am currently coding a bot that basically acts as a system for one particular server, and isn't intended to be used as a public bot. But I still wanted to add commands in that makes it simple for administrators to configure the bot inside of Discord, all was well, until I ran into the issue of trying to check if a channel ID is actually correct or not when executing the command, but unfortunately I kept getting error after error after error.
#bot.command()
async def channel(ctx, type, id):
global channel_report
global channel_approve
if id != discord.TextChannel.id:
await ctx.send("Command terminated: bad id.")
return
if type == "report":
#code here
elif type == "approve":
#code here
What have I been missing? I have tried to approach this many different ways, even with methods such as get_message , but got nowhere, and as a newish programmer, but especially new to the Discord API in particular, I'm lost. Thanks for all of those who are dedicating their time to help me, computer coding is just one of them interests.
I'm assuming what you mean by "checking if a channel ID is correct" is that you want to make sure the given ID represents an actual channel that the bot can access. You can use bot.get_channel() to get a channel object from an ID. If the channel doesn't exist, it returns null. So you can just check if it is null.
channel = bot.get_channel(000000000000000000) # try to get a channel which doesn't exist
if channel is None: # will return true as invalid channel returns null
await ctx.send("Command terminated: bad id.")
return

What’s the meaning of “General variable binding error” in SNMP4J?

I use gettable to query some data successfully in one machine,but when I use the same command to query the other machine,it returns “General variable binding error”.How to fix it ? I can query the data in command line using Net-SNMP in the other machine.
That error message is defined in SnmpConstants.java as part of SNMP_ERROR_MESSAGES,
https://github.com/kaazing/snmp4j/blob/60518cb185e7738f94a9c754e85fa220afeffe6d/src/org/snmp4j/mp/SnmpConstants.java
You can see the error message is being used only in PDU.java,
https://github.com/kaazing/snmp4j/blob/60518cb185e7738f94a9c754e85fa220afeffe6d/src/org/snmp4j/PDU.java
and is only used when the SNMP response message has an error status of 5, aka GenErr.
That's unfortunately an ambiguous error reported by SNMP agents when they hit an exception that cannot be categorized to other error status.
So in your case,
try to use SNMP v2 to perform the queries and it usually gives a better error status code (v2 introduced more codes).
accept the fact that GenErr can happen and handle it (or ignore it).
Since it is an agent side behavior to return GenErr, you have no other option on the manager side.

Put a user on hold with Amazon Lex

We are using Amazon Connect, Lex and Lambda to create a phone bot. One use case we have is that we need to put the user on hold while we find information in other systems. So the conversation will be something like this:
- bot: hi, what can I do for you?
- user: i want to make a reservation
- bot: wait a minute while I fetch information about available rooms
... after 5 seconds ...
- bot: I found a free room blah blah
I don't see a way to send the wait a minute... message and keep control of the conversation. How can we achieve that?
You can accomplish this inside a single Lex bot by setting the intent to be fulfilled by a lambda function, the response of the function would play a message saying “please wait” and then chain another internet to perform the search using the data from the original intent.
See this link for information about sharing data between intents.
You can chain or switch to the next intent by passing the confirmIntent dialog action back in the lambda response. See this link for more information on the lambda input and response format.
You can use wait block in aws connect https://docs.aws.amazon.com/connect/latest/adminguide/flow-control-actions-wait.html
By using this block you can set time to 5 secs . after time expired you can play prompt.
This is a very common problem typically when we want to do backend lookups in an IVR. The problem is lex does not provide any means to just play prompts.
One way to do it is:
Create a dummy slot in your intent (the reservation intent from your example above) with any type (e.g. AMAZON.NUMBER), we don't really care what the value is in this slot
From the lex code-hook for the intent, return ElicitSlot for this dummy slot with prompt as "Wait a minute while I fetch available rooms... "
If you do only this much, the problem you will face is that Lex will expect input from caller and will wait for around 4 seconds before passing control back to the Init and Validation Lambda, so there will be unnecessary delay. To overcome this, you need to set timeout properties as session attribute in "Get Customer Input" block from connect.
Property1:
Lex V2 Property name: x-amz-lex:audio:start-timeout-ms:[intentName]:[slotToElicit]
Lex Classic Property name x-amz-lex:start-silence-threshold-ms:[intentName]:[slotToElicit]
value: 10 (or any small number, this is in millseconds)
Property2:
Only available in Lex Classic, to disable barge-in on Lex V2, you can do it for required slot from lex console
Property name: x-amz-lex:barge-in-enabled:[intentName]:[slotToElicit]
Value: false
If barge-in is not disabled, there is a chance user may speak in middle of your "Please wait..." prompt and it will not be played completely.
Official documentation for these properties:
https://docs.aws.amazon.com/connect/latest/adminguide/get-customer-input.html
https://docs.aws.amazon.com/lexv2/latest/dg/session-attribs-speech.html
Another way:
Whenever such a prompt needs to be played, store the lex context temporarily either as a contact attribute after serialization, or if too big in size to be stored as contact attribute in a store like dynamodb.
Return control back to connect, play the prompt using 'Play prompt' module in connect. To give control back to bot, you will need invoke a lambda to re-initialize Lex with the full lex context again- using PostText API and then again passing control to same bot using 'Get Customer Input'
I have implemented option1 and it works well. You can even create cover-prompt which gets played if the backend lookup takes longer than expected. The actual lookup could be delegated to another lambda so that the code-hook lambda can continue doing customer interaction ever x (say 5) seconds to keep them informed that you are still looking up information.

error: No usable messages given the current slot and sessionAttribute set

I made a chatbot in lex and for one particular intent, Lex is throwing the error,
An error has occurred: Invalid Bot Configuration: No usable messages
given the current slot and sessionAttribute set.
This error comes regardless of the input in case of that intent.
I am not using any lambda functions at this point for this intent.
Can someone guide me what this means? I am new to lex and I did not find references to what this error is about.
Recently I got the same error with the test of my bot after saving some changes. After a while, finally, I found out that it was because my confirmation message was using some slots not defined at that point.
Example:
Let's assume we have:
one required slot {name}
one optional slot {age}
and the confirmation message is "Your name is {name} and your age is {age}, is that right?"
If Lex reaches the point to ask for the user confirmation and {age} was never assigned whether in any utterance or a lambda function, then Lex will return this error.
You must ensure that all slots used in messages are defined.
I believe this error occurs because you have not configured Lex to have a response message set for that particular intent's CodeHook or Fulfillment.
If you are not using a Lambda Function for Fulfillment, be sure to select 'Return Parameters to Client' in the 'Fulfillment' section, then also supply a response message below that in 'Response' section.
Here's where to find that in the Lex Console:
when I had the error it was because my response was attempting to use a slot that I had deleted {reward}, check your response to make sure you are not attempting to add an inactive slot. Also, Make sure your intent is set to the Latest version.

Why does Rxjs unsubscribe on error?

In short:
How to proceed listening after an error in stream without putting a .catch before every .subscribe?
If you need more details they are here:
Lets assume I have a Subject of current user or null. I get the data from API sometimes and send to the Subject. It updates the view accordingly.
But at some point error occurs on my server and I want my application to continue working as before but notify some places about the error and KEEP listening to my Subject.
Initially I thought that if I just do userSubject.error(...) it will only trigger .catch callback and error handlers on subscribes and skip all success handlers and chains.
And if after I call userSubject.next(...) all my chains and subscribers will work as before
BUT unluckily it is not the case. After the first uncaught .error it unsubscribes subscribers from the stream and they do not operate any more.
So my question: Why???
And what to do instead if I want to handle null value normally but also handle errors only in some places?
Here is the link to RxJs source code where Subscriber unsubscribes on error
https://github.com/ReactiveX/rxjs/blob/master/src/Subscriber.ts#L140
Rx observables follow the grammar next*(error|complete)?, meaning that they can produce nothing after error or complete notification has been delivered.
An explanation of why this matters can be found from Rx design guidelines:
The single message indicating that an observable sequence has finished ensures that consumers of the observable sequence can deterministically establish that it is safe to perform cleanup operations.
A single failure further ensures that abort semantics can be maintained for operators that work on multiple observable sequences.
In short, if you want your observers to keep listening to the subject after a server error has occurred, do not deliver that error to the subject, but rather handle it in some other way (e.g. use catch, retry or deliver the error to a dedicated subject).
Every Observable emits zero or more next notifications and one error or complete but never both.
For this reason, Subjects have internal state.
Then it depends how you construct your chain. For example you can use retry() to resubscribe to its source Observable on error.
Or when you pass values to your Subject you can send only next notifications and ignore the other two:
.subscribe(v => subject.next(v));
Or if you want to throw error when the user is null you can use any operator that captures exceptions and sends them as error notifications. For example like this:
.map(v => {
if (v === null) {
throw new Error("It's broken");
}
return v;
})
Anyway it's hard to give more precise advice without any code.

Resources