According to the Conversations API documentation in the case where a pre-action webhook fails to get a response:
(no response or timeout)
then
Conversations will publish the change unmodified after a series of retries; your messages will be delayed accordingly.
However it looks like the actual result is that Twilio returns an error to the mobile SDK when the webhook post times out.
Honestly the current response is the one I was hoping for, but since the documentation makes it seem like this is a bug, I just wanted clarification of what the expected result SHOULD be, before making any assumptions that break my stuff later on.
Related
How can we "like" or add other reactions to someone else's channel message or comment via the Graph API?
I've not done this myself, but it certainly looks possible. You need to reply to the message, as per https://learn.microsoft.com/en-us/graph/api/channel-post-messagereply?view=graph-rest-1.0&tabs=http and notice that it has a "reactions" collection. That would be populated with a chatMessageReaction type, as per https://learn.microsoft.com/en-us/graph/api/resources/chatmessagereaction?view=graph-rest-beta
Note of warning: chatMessageReaction is a beta type though, so just be aware you need to call the beta endpoint, and it has a risk to use in production code as things might change.
Update: We reached out to MS Support and received the following info: "The API to reply to a message using a POST /replies request is solemnly for issuing a reply to a message, and not to edit the status of the parent message itself. Moreover, the "update chatMessage" API which is a PATCH /messages and which is the only API to edit a parent message only supports updating the policyViolation property of a chatMessage. Essentially, there is currently no documented API / already-present API examples on how to add a reaction, making this purely unsupported."
I'm currently running a web application that uses Microsoft Graph's API and we encountered the following message today which severely impacted our application, for a whole day:
"error": {
"code": "ErrorTooManyObjectsOpened",
"message": "Too many concurrent connections opened., The process failed to get the correct properties.",
"innerError": {
"request-id": "removed",
"date": "2017-12-13T17:01:14"
}
}
please note that the request-id was removed
Let me summarize what our web application does.
Basically, we have 2 email folders that we are actively subscribed to, Junk and Folder A.
If anything hits Folder A, we strip the body of the email message and then move the message to Folder B. The subscription on our Junk folder also strips the body and sends them over to Folder B.
Sometimes the webhook subscription service skips messages that may come at the same time, therefore we have 2 cron jobs in our server that run a script and check Junk/Folder A for any messages every 5 minutes, therefore my assumption is that the cron job runs about 288*2 times per day. Not counting our subscription to the folders, we usually get around 200-300 email messages per day.
Unfortunately Microsoft's Graph error codes page does not provide us with any explanation about this code. I would really appreciate if anyone can explain what this means and how to avoid it from happening.
This is occurring because your application is exceeding the throttling thresholds.
There are several different throttling metrics that can affect Microsoft Graph requests. For a high-level overview, see the Microsoft Graph throttling guidance. Since in this case you're hitting Exchange Online via Graph, you can find more specific information from What throttling values do I need to take into consideration? in the Exchange documentation.
Architecturally, you are making a lot of unnecessary calls into the API. Rather than having both a subscription and a scheduled job, you should use just the webhook subscription and the /delta endpoint.
Each call to the /delta endpoint gives you a token that can be used to fetch any changes to a given resource since the token was originally issued. So regardless of if 1 email came in or 1,000, you only get the new emails.
Once you're using the /delta to find your changes, you then use a webhook only as a "trigger". When you receive the webhook, you can ignore the contents and instead issue a request to /delta. This ensures that you capture every incoming email even if you didn't necessarily receive separate webhook notifications.
There is a bug. After making 500 message move requests, a "cannot copy/move error" occurs. Subsequently, a "429: Too many concurrent connections opened" error occurs. Most applications miss the first error because you continually get the 429 error afterwards.
If you let the application "rest" for 30 minutes, the throttle resets itself and you can continue on. I do not think there is a time limit for hitting the 500 moves. My application did 500 moves after 6.5 hours and then we started getting the error.
And, if you keep trying your move call before the 30 min rest period, it never resets. Also, in the response, the retry-after is null... so, that doesn't help you.
If you find a work around, please let me know. We are trying a few things like setting the category, then manually moving the messages. I am also investigating making a rule the moves them for us or some other job. I cannot find a way to execute a rule from the Graph API.
See this link for more information. Also, the more people who report having this issue, hopefully the sooner it can be resolved. Outlook API Throttling documentation #144
So I have implemented the Asana Webhooks API as described in their documents. I can pass it a project ID and request a new webhook be created. The API successfully sends a authentication request to my application which returns the Security header as described in the Docs. Asana then returns the expected success response, outlining the newly created Webhooks unique ID.
Now if i take this ID and then query the Asana API to show me all configured webhook's on either the parent Workspace or the project resource directly it returns an empty data JSON Object or reports the resource doesn't exist, suggesting the Webhook Ive just created wasn't actually created, despite giving me the expected success response.
Also If I then make a change to a project it doesn't fire the webhook and I don't receive any events on my application.
Strangely everything was working on Friday but today (Monday) I'm experiencing these issues.
Any pointers would be good, Ive been working as the Docs suggest in terms of my request structure and am authenticating using a PAT, Ive even tried a newly created token.
Thanks,
Our webhooks use the handshake mechanism to make sure that it's possible to call you back, but there's always the possibility that subsequent requests can fail. Additionally (although we don't document this very well - there's an opportunity for us) we should immediately try to deliver a (probably) empty event after the handshake (it looks like {"events":[]}. This is kind of like a "second callback" that contains anything that has changed since you created the webhook.
If this fails - or if any subsequent request fails often enough - the webhook will get trashed. "Failure" in this context means returns HTTP response codes other that 200 or 204.
As for why you're having trouble querying the webhook itself, I wasn't able to repro the issue, so we'd have to dive deeper. It should be fine if you:
Specify the workspace
Optionally specify the resource
I tested this out, and it seemed fine. You also might want to directly query the webhook by id with the /webhooks/:id endpoint - note to use the id of the webhook returned by create, and not the id in the resource field.
If you created the webhook (specifically, your PAT or OAuth app was the one making the create request) you should see the information just fine. If you can get the webhook by id, you should see last_failure_at and last_failure_content fields which would tell you why the webhook was unable to make the delivery.
Finally, if you would like to contact us at api-support#asana.com and let them know more details (for instance, the ID of the webhook you're trying to look at) we can look at those fields from our side to see if we can identify what's going on.
I'm using the one-time code flow with my google+ sign in button implementation, but the user_id in the response from the tokeninfo endpoint doesn't match the id_token in the object my javascript my javascript callback receives from the sign in buton.
In the sample code in the documentation, the the user_id in the tokeninfo object is checked against a request parameter called gplus_id, but the sample javascript doesn't send this parameter, so I have no idea if I'm checking against the right thing.
So, to be clear about the particular sections of code I'm talking about:
The one-time code is processed on the server using this sample code, and it uses a request parameter called gplus_id.
The code in this section sends the one time code to the server, but as I can see, it doesn't send a gplus_id
It looks like step 6 on the example page is incomplete, and is supposed to be sending the gplus_id, but isn't.
Take a look at the connectServer function (and the function that calls it) in https://github.com/googleplus/gplus-quickstart-java/blob/master/index.html for a more complete example of how to get the user's ID and pass it to the server for verification.
(And I'll try to ping the people responsible for the documentation to get it updated and consistent across the platforms in the quickstart examples. You can also track bug 573 to see progress on them fixing the documentation.)
NOTE: It is worth noting, however, that sending the gplus_id is a bit redundant. You're already trusting the code sent from the client, and you're getting the ID through steps derived from the code. So while passing and checking the gplus_id is a nice sanity check, it really doesn't gain you any additional security.
I'm trying to use the FedEx API to track packages. I can authenticate to their test server successfully (using my user credentials, account number, and meter number). However, I receive the same unhelpful response for most tracking numbers that I use in my requests; both test tracking numbers (like 999999999999) and real tracking numbers (that work well on the FedEx website) return the following:
Error Code 9040.
No information for the following shipments has been received by our system yet. Please try again or contact Customer Service at 1.800.Go.FedEx(R) 800.463.3339.
The only requests that fetch a different response are the clearly invalid ones, like "test", which returns:
Error Code 5508.
Invalid tracking number.
I tried SOAP requests using their wsdl (TrackService_v5) as well as manual non-SOAP HTTP POST requests, but their responses are exactly the same in both cases. Is something wrong on their side, or am I doing something wrong?
It seems that FedEx has disabled any test tracking numbers, in the past 999999999999 would work just fine, but now that doesn't even work. To the best of my knowledge, the only way to resolve this is to move to production. Which IMHO is bad because you have to test the tracking part of your application until you move to production.
999999999999 worked for me, but I think I am already in production environment.