When I send data to Chatbase, I receive a message_id and status 200, but nothing appears in the overview. Even after 6 hours. Is this a common problem and how can I fix it?
It can typically take up to an hour to begin seeing your messages on the Overview reports. However, depending on your timezone and the date range you select, it could be delayed further. If you are still experiencing the issue, you can contact chatbase-support#google.com with the api key of your bot and I will be happy to look at your bot messages to assure that everything is in order.
Related
I am making a bot on Dialogflow with a Fulfillment. Considering the given strict 5-second window in DialogFlow, I am getting [empty response] as a response.
I want to overcome this issue, but my web service requires more than 9 seconds for the execution.
I am considering to redesigning the conversation flow in such a way that we will start streaming audio till the Response is processed.
Example:
User Question: xx xxx xxx xxxx xxxxx?
Response: a). We'll play fixed audio to keep the user engaged for few seconds till it finds a response text in the back end; b).
Receive answers from the web service and save them in the session to
display further.
How can I achieve this and how can I handle the Timeout issue?
You're on the right track, but there are a number of other things to consider.
First, however, keep in mind that anything that is trying to "avoid" the 5 second timeout already indicates some issues with the design. Waiting 10 seconds for a reply is a pretty long time with something as interactive as voice! Even 5 seconds, which is the timeout, is a long time. (And there is no way to change this timeout.)
So the first thing you may want to do is consider if there is a better/faster way to do what you want.
If not, the rough approach would be something like this:
Get the request from the user.
Track a unique identifier, either tied to the user or tied to the session. You'll be using this as a key into some kind of database or data store.
Start the API call as part of an asynchronous request or in another thread.
Reply immediately that you're working on it in a way that the user will send another request. (See below for this issue.) You'll want to make sure that the ID is maintained as part of this session - so you'll need to save it as part of the Session data.
At this point - you're basically doing two things in parallel.
When the API call completes, it needs to save the result in the datastore against the identifier. (It can't save it in the session itself - that response was already sent back to the Assistant.)
You're also waiting for a reply from the user. When it comes in:
Check to see if you have a response saved for this session yet.
If not, then go back to step 4. (You may want to track how many times you get here and give up at some point.)
If you do have the result, reply to the user with the information.
There is an issue with how you reply in step 4, since you want to do something that will guarantee you another request from the person expecting an answer. There are a few possible approaches:
The most straightforward way would be to send back a Media response to play a few seconds of "hold music". This has the advantage that, when the music stops, it will send an event to Dialogflow which you can capture as an Intent and then continue with step 5.
But there are some problems:
Not all versions of the Assistant support the Media response. You will need to check to confirm the feature is supported before you use it and, if not, use another approach (see below).
The media player that is presented on some Assistants allow the user to stop playback, or will not correctly send an event when the audio stops in some situations. So you may never get another request in this session.
Another approach involves some more advanced conversation design tricks, so may not always be suitable for your conversation. Your response can say that you're looking up the results but then ask the user a question - possibly one that is related to other information that you will need. With their reply, you can collect this information (if you need it) and then see if you have a result yet.
In some conversations - this works really well. For example, if you're looking up flights to somewhere, while you're looking that up you might ask them if they will need a hotel or rental car, which you might ask about anyway.
Other conversations, however, don't easily have such questions. In these cases, you may need to ask something that isn't relevant while you stall for time.
I am creating a chatbot which have an intent with a payment link. So on trigger of this intent, I made call from webhook fulfillment to third party api which takes approx 20secs to respond. But in this period of time my response is timed out as it is limited to 5 sec from google.
Can you please suggest what approach should I follow. I just want to wait for approx 20 sec to respond.
Thanks.
one option is to keep the conversation alive using events (generated by the webhook) which trigger dedicated intents.
When a payment must be performed the webhook starts a background process to deal with the 3rd party payment API, and sleep for 4-5 sec, after that generates an event (setFollowupEvent PAYMENT_IN_PROGRESS). This event is associated to a DialogFlow Intent which fires as soon as the event is sent back to the platform.
At this point you have another incoming webhook call: check status of the payment, if it is still in progress (likely after 5 sec) then sleep 4-5 sec and send another event (setFollowupEvent PAYMENT_IN_PROGRESS_2) which produces the same workflow.
There are so many times you can do this (I think a max of 3), so you need to cater for the fact that the payment does not terminate in time (fallback scenario).
A smart option could be to keep engaging the user with the conversation, not always easy, depending on what your chatbot is about.
Hope it helps.
The short answer is that you can't.
The longer answer is that you need to think about this as a conversation. If you asked someone a question, and didn't get any response from them for 20 seconds - that would be pretty uncomfortable, wouldn't it?
Instead, we have come up with ways to compensate for that silence. In a physical conversation, people may engage with you and ask you questions to fill the time. If you're on the phone, they may play hold music. Or we may end the conversation for now and tell them later when there is a result.
When building an Action, we have similar parallels that may work better or worse based on our exact needs.
Engaging in conversation
One approach is that when we get the request from the user, we do two things:
Start a task that will execute the query and save the results in a separate "answer database", indexed against the user, a session ID, or some other temporary id we can generate and use later.
While the query is running, we reply to the user saying we're working on it, and asking them another question.
Then, when they reply with their answer to this other question, we can check if we have an answer for them in the database. If we do, we'll reply with it. If not, we'll repeat step 2 until we do.
This approach works well if we either have other questions to ask, or if we're in a good place to "make small talk". Picture booking an airline reservation - while we look up flights, we may want to ask if they prefer window or aisle seats (Which we'd need to ask later) or make small talk by asking if they're traveling for business or leisure.
Using "hold music"
A variant of this allows us to play some hold music while we're processing the answer.
Instead of asking a question in step 2 above, we reply with a Media Response that plays 20 seconds or so of music. When the music completes, our fulfillment webhook will be sent a MEDIA_STATUS event and we can either return the information from the answer database, or say we're still working on it and play more music.
This is less conversational, but may work better if we don't actually have anything to say in the meantime.
Sending a notification
If the response may take a very long time, then it may just be best to let them do other things and to send a notification or a text or email when you have a result. These cases, however, require the user to have registered with you in some way and are probably more appropriate if you have a long-standing relationship with the user.
Summary
You should be returning results as quickly as you can to keep it feeling like a conversation. When you can't, consider other means, just like how we would consider what it would be like if we were talking to another person.
Recently I am heavily dealing with Docusign Api. Especially Bulk Send Rest api method since we have requirements to send 30K envelope in 3-4 hours. Given the Api Rule Limits, led us to leverage bulk send feature.
Since Bulk send has some limitation, like it has its own queue mechanism where queue size can not exceed 2000, I am implementing my solution by respecting to this limit.
To do that, I divided my bulk recipient file (30 K recipient) into 30 CSV file.
Then I initiate for each loop and inside the loop I am controlling queue size if the queued item count became 0 for the batch. During my many tests even though all email has been reached to my inbox, I have never seen queued property to become 0. If it would become 0, then I would send the next batch. But I could never do that
Below is the screenshot I took from ApiExplorer.
If I look deeper for Trial 3 to see what are those 24 queued items as seen below.
I am getting following response.
As you can see from the latest screenshot, even though queued property indicates that there are some pending items, resultSetSize property shows 0 although I just queried queued items.
For this reason I am not able to build my logic based on sent, queued, failed property value. I thought, I could rely on them to successfully build my logic. If not, how can I overcome this problem ? Any help would be appreciated.
Thank you in advance
I am looking for the following feature in Gmail.
For each message I open, it tracks the time I spent reading the message when it is feasible to do so. For example, if I open message 1 and then move to message 2, by clicking a button within 2 seconds, it notes that the time spent on message 1 is less than 2 seconds.
Gmail automatically labels the messages on which the User spends less than some configurable amount of time (say 2 seconds) and assigns them a label, say "LowAttentionSpan". This way the user can periodically look for messages with this label and take actions like unsubscribing from a list to minimize the amount of time spent on the Inbox.
Is such a feature already available now or can it be developed using Gmail API?
I believe this feature is not yet available for Gmail. Referencing the documentation, there are no such labels similar to what you are looking for nor can you customize to have such labels.
As gerardnimo said, there is currently no such feature available for Gmail. An approximate solution using the Gmail API comes to mind though:
Subscribe to push notifications and issue a watch on the UNREAD-label.
Every time you get a push notification related to a certain user, it will mean that the user just started reading a mail (or marked an old mail as UNREAD). Check the difference in time since last time you got a notification for the same user. If the difference was less than LowAttentionSpan seconds, you could add a custom label to it.
This simple solution has some caveats though.
If the user marks an old message as unread, it might cause some unwanted behavior.
Also, if the user reads only one mail, and comes back e.g. three hours later to read another one, the solution above will interpret that as the user read the first mail for three hours, which will not be the case. It will in other words just work when the user reads multiple new mails in succession.
According to Stripes documentation here if you add a Stripe object ID as the source when getting a list of balance transactions you should get all transactions related to that ID. (e.g. filtering by a charge ID will return all charge and refund transactions).
I have tried passing in a chargeId and do indeed get back the initial balance transaction that was created for that charge, however this charge also has 2 refunds associated with it that are not returned in the list. I have tried this with other charges and only ever seem to get back the initial balance transaction created, never any other transactions (particularly refunds which the docs say should be returned). I have my limit set to 100 items and I have tried using both the Stripe.Net API as well as PHP calls and get back the same results.
I've also attempted passing in customerId's to see if I could get back all balance transactions triggered by a Customer and in these cases I never get back any results at all. These are Customers that have triggered MANY transactions!
The arguments I am providing to the API are as follows:
Method: balance/list
Parameters: limit=100
source=[chargeId or customerId that has triggered multiple transactions]
My question is: Is this a bug in the API, is the documentation incorrect or is there an important parameter or aspect to this I am missing. I've also gone back to charges from 30+ days ago just to make sure it has nothing to do with the rolling transfer/pending/availability cycles.
Is the actual fact that you can only ever get back the initial transaction created by a chargeId, but nothing else. Anyone have any experience in this regard? Thanks in advance!
Looks like this is indeed either a bug or an error in the Stipe documentation. I've reported this to Stripe and just received the following message back from someone on the support team:
Hi there,
Thanks for reaching out and alerting us to this issue!
This does look like either a bug or an error in our documentation. I have shared this with my team and we are looking into this issue.
Thank you for using Stripe and please let me know if there's anything else we can do to help!
I will update this thread once I hear back from Stripe with either an update or a resolution.
My hunch is this isn't a bug: the Stripe behavior is technically correct. The BalanceTransaction API is returning all txns for that specific charge, which is only a single txn. The txns associated with the charge's refund are technically associated with those refund objects, not the charge. The same logic applied to disputes/chargebacks.
Here's some (untested!) ruby code demonstrating how to grab all of the txns for a charge:
def balance_transactions_for_charge(stripe_charge_id)
balance_transactions = []
charge = Stripe::Charge.retrieve(stripe_charge_id)
balance_transactions << charge.balance_transaction
balance_transactions += charge.refunds.data.map do |refund|
refund.balance_transaction
end
if charge.dispute
dispute = Stripe::Dispute.retrieve(charge.dispute)
# fairly certain that the dispute txn list includes the full object, not just IDs
balance_transactions += dispute.balance_transactions.data.map(&:id)
end
balance_transactions.map { |txn_id| Stripe::BalanceTransaction.retrieve(txn_id) }
end