I'm implementing a Handler for the DISCONNECT Intent, and by reading the online documentation https://developers.google.com/assistant/smarthome/reference/intent/disconnect, I see that it is no such response format and it is not a reference in case of fail event, when for example we return an error in event that we didn't properly handle the disconnect or Google API did not reach our server. Does Google Assistant implement some sort of automatic retry logic so that in event of error it automatically resends the requests for a certain amount time. In other words is it a way to tell to the google assistant to retry or return some error to the user that made the DISCONNECT request?
There is no response format for the DISCONNECT intent in the https://developers.google.com/assistant/smarthome/reference/intent/disconnect documentation because nothing is returned when the action.devices.DISCONNECT intent is executed (eg. Google does not retry based on your response status code). You can find more information on this at https://developers.google.com/assistant/smarthome/develop/process-intents#unlink
After an action.devices.DISCONNECT intent is sent, the Assistant stops sending any more intents for the user who has just been disconnected, and the associated cloud service also stops calling Home Graph APIs (Request Sync and Report State) for their devices and a SYNC request is triggered.
Related
Imagine there is an app where a user has a wallet which they can top it up with cash, cash it out or make purchases from an external system, when the user creates a new purchase order, we first deduct the amount from the user’s wallet. Then send an API call to the external API saying the user purchased these items and we get a response back from the merchant on whether the purchase was successful or not. If the purchase was not successful, we would refund the amount to the user’s wallet on our system. However, one key note here is that the merchant purchase API endpoint could return error responses that are domain errors (user is not registered, user has been deactivated, purchase is less than minimum allowed amount or above maximum amount) and the user gets an immediate confirmation response on whether the transaction was successful or not, and if not, we show the user the failure reason we got from the external API
I’d like to apply saga to the flow above but there are some challenges
Let’s say we’re going to be using a message broker (Kafka, rabbitmq) for async saga flow, how do we return a response to the user on whether the transaction was successful or not? The async transaction could fail for any reason, and if it fails it might take a while to process retries or even rollbacks in the background.
And even if we were able to let’s say notify the front-end/user of the result using something like webhooks where we push data to the client. What happens on timeouts or technical failures? Since the flow is async, it could take either a second or an hour to finish. Meanwhile what should the user see? If we show a timeout error, the user could retry the request and end up with 2 requests in pending state that will be processed later on but the user’s intention was only to make one.
I cannot show the user a successful message like “Purchase created” then notify them later on for two reasons:
The external API returns domain errors a lot of the time. And their response is immediate. So it won’t make sense for the user to see this response message then immediately get a notification about the failure
The user must be able to see the error message returned by the external API
How do we solve this? The main reason behind attempting to solve it with saga is to ensure consistency and retry on failure, but given that, how do we handle user interaction?
This is how I would solve this through temporal.io open source project:
Synchronously (waiting for completion) execute a workflow when a user creates the purchase order.
Workflow deducts the purchase amount from the user's wallet
Workflow calls the external API
If the API call completes without failure complete the workflow. This unblocks the synchronous call from (1) and shows the status to the user.
If the API call fails start (without waiting for the result) another workflow that implements the rollback.
Fail the original workflow. This returns the failure to the caller at (1). This allows showing the error to the user.
The rollback workflow executes the rollback logic as long as needed.
Here is the implementation of the above logic using Java SDK. Other supported SDKs are Go, Typescript/Javascript, Python, PHP.
public class PurchaseWorkflowImpl implements PurchaseWorkflow {
private final ActivityOptions options =
ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(10)).build();
private final Activities activities = Workflow.newActivityStub(Activities.class, options);
#Override
public void purchase(String accountId, Money amount, List<Item> items) {
WalletUpdate walletUpdate = activities.deductFromWallet(accountId, amount);
try {
activities.notifyItemsPurchased(accountId, items);
} catch (ActivityFailure e) {
// Create stub used to start a child workflow.
// ABANDON tells child to keep running after the parent completion.
RollbackWalletUpdate rollback =
Workflow.newChildWorkflowStub(
RollbackWalletUpdate.class,
ChildWorkflowOptions.newBuilder()
.setParentClosePolicy(ParentClosePolicy.PARENT_CLOSE_POLICY_ABANDON)
.build());
// Start rollbackWalletUpdate child workflow without blocking.
Async.procedure(rollback::rollbackWalletUpdate, walletUpdate);
// Wait for the child to start.
Workflow.getWorkflowExecution(rollback).get();
// Fail workflow.
throw e;
}
}
}
The code that synchronously executes workflow
PurchaseWorkflow purchaseWorkflow =
workflowClient.newWorkflowStub(PurchaseWorkflow.class, options);
// Blocks until workflow completion.
purchaseWorkflow.purchase(accountId, items);
Note that Temporal ensures that the code of the workflow keeps running as if nothing happened in the presence of various types of failures including process crashes. So all the fault tolerance aspects are taken care of automatically.
After saving a data, I wait for the confirmation of the opposite server. With a different endpoint, I want to constantly check this server's approval check in the background. I want to send requests continuously until the transaction is approved and when it is approved, I want to take action. How can I make a request to a persistent endpoint?
From which sources should I get help, if there are examples, I would like to examine them.
How is a "SUBSCRIBE" request can terminate a SIP dialog ?
You should find all your answers in rfc6665. You may take a look more precisely at Section 4.2.1.4. Refreshing of Subscriptions and Section 4.4.1. Dialog Creation and Termination
Quoting some text of the rfc:
Here is the way to request the end of the dialog from subscriber side:
Clients can cause a subscription to be terminated immediately by
sending a SUBSCRIBE request with an "Expires" header field set to
'0'.
And the final NOTIFY that really terminates the dialog:
A subscription is destroyed after a notifier sends a NOTIFY request
with a "Subscription-State" of "terminated", or in certain error
situations described elsewhere in this document.
I have followed the steps to setup the Facebook Messenger platform. The verification GET web hook request work perfectly, as does the subscribe but when I submit the chat I keep getting the follow Developer Alert:
Hi Norah,
We've noticed that your Webhooks subscription for callback URL https://{domain}/v1/webhook has not been accepting updates for at least 16 minutes. Please verify that your callback server is functioning so you may continue to receive updates. If you need to update your callback URL, see https://developers.facebook.com/docs/messenger-platform/webhook-reference#webhook_setup
If your callback URL continues to fail to accept updates for 8 hours straight, we will disable your subscription. To reactivate the subscription, make a POST request with the same parameters, and it will be reactivated.
My post request works through POSTMAN.
Please can someone help me! This is driving me nuts!
Do you have logs on your server for that post requests?
Facebook requires you to return status code 200 for the post request, so they know that you successfully received it. When they havent, they try it again and if that still fails after several times, they will give you this alert.
Maybe facebook uses another content-type or message content than you used with postman.
Your server logs should give you more insights about that.
Depending on what Webhook events that you have subscribed for a page, there will be callbacks for those events, and more, on the url you have specified in the Web Hook set up.
If you had subscribed to the message_deliveries event, every time a message is sent, whether from a user to your page or from your page to a user, there is a, maybe more, calllback with a Message Delivered json object. The Webhook Reference has an example of the Message Delivered json object, but no specification or explanation on what the fields mean.
Occasionally I find that an undocumented Read callback is received, sometimes. The undocumented json data for this is like:
{"object":"page",
"entry":[
{
"id":"1722858134648129",
"time":1465407550812,
"messaging":[
{
"sender":{"id":"1131485883560113"},
"recipient":{"id":"1722858134642218"},
"timestamp":1465407550868,
"read":
{
"watermark":1465407548057,
"seq":428
}}]}]}
Essentially, you must code your callback to handle ALL types of json data gracefully, including unknowns, even though you may not be ready to process them further. For those that you are not ready to handle or uninterested in, return nothing with Http status code 204 (in fact every callback should return 204 as the type is void).
If you handle only those types of json data you are interested in, any unexpected json data will most likely raise an exception in whatever language your web callback code is written in and result in a 500 server error returned to Facebook. It is this 500 error that is causing Facebook to make that complaint in your question.
Twilio has provision for configuring callback URL while sending SMS, which is notified of events relating to changes in the delivery state of SMS.
What happens if my application misses one of these callback events? Say for example when my server is down and the callback request encounters a 502 or 500 response.
Does Twilio retry the callback?
If yes, how many attempts are made before abandoning the event notification?
Hope this thread isn't SUPER dead...
I set out to solve this problem myself by making twiliq.com. Disclosure: I'm the dude that made this thing.
You set it as your backup URL endpoint and it'll replay the message as often as you configure until your server recovers.
Twilio developer evangelist here.
Twilio webhooks (for SMS or phone calls) do not make retry attempts to the same URL if your application fails to respond with a 200 response.
However, you can supply a fallback URL that Twilio will request with the same parameters if your primary URL fails. We recommend that this fallback URL is not part of the same application so that if your main application is down, you can recover and continue the conversation, save the errors for later or return an error message to your user.
There is more detail on how best to use fallback URLs on the Twilio site.
Since an answer was posted for this Twilio has added support for retry attempts on webhooks. By default it will retry once on TCP connect or TLS handshake failures, but the type of failures it retries for can be adjusted and the number of retries can be set anywhere between and including 0 and 5.
Documentation can be found here:
https://www.twilio.com/docs/usage/webhooks/webhooks-connection-overrides