Occasionally when sending an email through the Office365 API, we get an error back:
excerpt:
{"httpCode":503,"headers":"HTTP/1.1 100 Continue\r\n\r\nHTTP/1.1 503
Service UnavailableX-MS-Diagnostics: Routing Validation; Mailbox
database change detected; moved from database 31f16b42-8c32-43a3-a05f-
f554bb4c579f to 78f2e7a1-e65f-4148-8be4-b98ac0635fdf\r\nX-
BEServerRoutingError: Mailbox database change detected; moved from
database 31f16b42-8c32-43a3-a05f-f554bb4c579f to 78f2e7a1-e65f-4148-
8be4-b98ac0635fdf"}
Does anyone know why this happens,its annoying when the client thinks your app is faulty, when its actually an error within the Office API which causes it.
You just made a call in the middle of a re-balancing operation. Just retry your call. For things like this, you shouldn't need to show them to the client.
Related
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
I am implementing an IMAP server, operating on messages shared with other systems and due to business needs users are not allowed to create or delete messages or mailboxes via the IMAP server.
In our production environment however, we often see the following three commands occur very often
15 EXAMINE "Drafts"
16 STATUS "Drafts"
17 CREATE "Drafts"
For all three we reply with a NO response, but when the user logs in again next time, we see the same commands being issued.
Is there a way to discourage the client from issuing these commands? The only folder that we have is INBOX.
In principle, a response code of CANNOT ("The operation violates some invariant of the server and can
never succeed") should get the message across, though I suspect few clients would react appropriately to such feedback.
I am using Ruby on Rails and I am trying to understand all the subtleties of HTTP codes to bring my app with standards, and I'm facing the following case.
Let's say I have a database with two tables, Companies and Employees.
If users try to delete a company with no employee, it is deleted and server sends code 200.
If users try to delete a company with employees, it is not deleted and server sends a message ("There are employees linked to this company..."). In this case, what code does server have to send ? I was thinking of HTTP 4XX but in my opinion, it is not a client error.
Use the 409 Conflict error code. It indicates that the request could not be processed because of conflict in the request.
Once the employees are gone then the conflict is removed and the delete will work. You can think of it as a client error in the sense that it is a conflicted request from the client.
If the client is not allowed to use the DELETE method on companies with employees, I would suggest 405 Method not allowed. Include an explanation of why in the response body.
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.
Whenever a web request is made by Visual Studio to TFS, Fiddler will show a 401 Unauthorized error. Visual Studio will then try again with a proper Authorization Negotiate header in place with which TFS will respond with the proper data and a 200 status code.
How can I get the correct headers to be sent the first time to stop the 401?
This is how the process of Windows Integrated Authentication (NTLM) works. NTLM is a connection based authentication mechanism and actually involves 3 calls to establish the authenticated session.
The TFS API then goes to extra-ordinary lengths to make sure that this handshake is done in the most efficient way possible. It will keep the authenticated connection open for a period of time to avoid this hand-shake where possible. It will also do the initial authentication using a HTTP payload with minimal content and then send the real message if the message you were going to send is over a certain length. It does a bunch of other tricks as well to optimise the connection to TFS.
Basically, I would just leave it alone as it works well.
You will see that a web browser also does this when communicating with a web site. It will always try to give away the minimum amount of detail with the first call. If this fails, it will reveal a little more about you.
This is by design and for a very good reason.
This is how it's always done - request, get the 401 back, then send the authorization. It's part of the authentication protocol for http.