Here you can see our application failing a POST to GA:
The next track of Application Insights has the following content:
As you can see the resultCode is 0 even thought the resulcode was 403. Any reason for that?
It is not a consistent error, some times it records the right resultCode while some times it does not. Well, it consistently fails on some requests but consistently succeeds on some others, it it not a random issue.
You can get the HAR from here: HAR file
Related
com.microsoft.graph.http.GraphServiceException: Error code: SyncStateInvalid
Error message: The sync state identified using the request token 'HzWyBB6EZsMOpd9NmgmVnqAnVEMAAAQ9rM8FAwAA' is no longer valid.
GET https://graph.microsoft.com/v1.0/users/6be2c2df-8e20-4f99/mailFolders/AQMkADlmY2YxNTY3LWVhNjItNDFhMS1iZDA0LWZ/messages/microsoft.graph.delta?$deltatoken=LztZwWjo5IivWBhyxw5rAHNeTrUj6tmJCwsicW9zTkZhNFWO0u7VKvvdkBxQHWUvDsSPLMpUBSlb3nEcc_qVbTk1hQlWa3MIyqHvnT47wRA.NIA-bd_JnbZrpOuTHnjHoWWo1K5QPy4CLrFTODjYn9c
Prefer : odata.maxpagesize=1
Prefer : IdType="ImmutableId"
SdkVersion : graph-java/v1.6.0
Authorization : Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI[...]
Hi guys, I'm getting the above SyncStateInvalid error, I've done a search, realizing that most people are facing SyncStateNotFound error instead.
Not sure if anyone faces this issue before and knows what is the fix.
I am trying to sync incremental mail messages based on the delta token.
I've tried to paste the same link in graph explorer, and was able to get result.
(This question replaces this one, hopefully with better information.)
I've got three servers that I'm gonna call Alice, Charlie, and Harry (Harry being the server's actual nickname, so as not to confuse myself). They all talk to each other to perform quite a complicated authentication flow:
A client performs a sequence of three requests through Alice to Harry.
On the third one, Harry makes a call to Charlie.
Charlie is prone to timeouts during periods of heavy traffic. If it does, Harry returns a 503 with a Retry-After header to Alice.
Harry is returning a 503, I have confirmed that in its own logs.
Alice is not receiving a 503 but a 500, and without the header.
Alice's other clients (which I'm not in control of) treat a 500 the same as other errors, which is what I'm ultimately trying to fix.
Some extra information, such as I have been able to ascertain:
Alice proxies calls to Harry using RestClient, which uses Net::HTTP under the hood.
Using Net::HTTP directly gives the same result.
It's not environment specific; I have had this problem both in Production and Development.
I have been trying to simulate Alice using Postman, but haven't had any luck yet; Charlie's traffic is quieter at the moment, and I can't force or simulate a timeout, so so far I've only been getting successful 200 responses from Harry.
Fixing Charlie's timeouts would obviously be ideal, but I'm not in control of Charlie's hardware either.
Is there something I can change about Alice so it properly detects Harry's 503?
Or, is it possible that something about Harry is changing its 503 to a 500 after it's returned and logged?
Here's Alice's code for that third call, if it's likely to help, but nothing's jumping out at me; I have been wondering if RestClient or Net::HTTP has some configuration that I don't know about.
http_verb = :post
args = [ # actually constructed differently, but this is a reasonable mock up
'https://api.harry/path?sso_token=token',
'',
{
'content_type' => 'application/json',
'accept' => '*/*',
# some other app-specific headers
}
]
RestClient.send(http_verb, *args) do |response, request, result, &block|
# `result` is present and has a 500 code at the start of this block if Harry returns a 503.
#status_code = result.present? ? result.code : :internal_server_error
cors.merge!( response.headers.slice(:access_control_allow_origin, :access_control_request_method) )
#body = response.body
end
Turns out it's something way simpler and more obvious than anyone thought.
A separate error was raised in the middleware responsible for returning the 503. As with any other exception, this got rendered as a 500.
The thing that was causing it was a line that was supposed to tell the client to wait five seconds and try again:
response.headers['Retry-After'] = 5
... some middleware component was complaining of undefined method 'each' on 5:Fixnum, because it was expecting an Array where it wasn't a String; it started working when we changed 5 to '5'.
I'm trying to post a user status update to the Goodreads API.
Most of the time my request returns 200 OK and does nothing. Every now and then, though, it returns 201 Created and the status is updated. When it works it's always the first time I try to make the call after running the app in iOS simulator. Subsequent calls never work.
I don't think the problem is the API itself, since the official Goodreads iOS app uses the same call and it always works.
Their API is famous for having problems with calls that include brackets in the parameters, but I can make other calls that contain brackets and they work fine, the problem is just this one.
I'm using OAuthSwift and this is my code:
oAuth.client.post(
"http://www.goodreads.com/user_status",//.xml",//?user_status[book_id]=6366035&user_status[page]=168",
parameters: ["user_status[page]" : 168, "user_status[book_id]" : 6366035, "format" : "xml"],
//headers: ["Content-Type" : "application/x-www-form-urlencoded"],
success: {
data, response in
print("")
print(response)
},
failure: {
error in
print("")
print(error)
}
)
(The commented out parts are alternatives I have tried unsuccessfully.)
I'm printing the base string that gets signed and it looks the same for the calls that work and the ones that don't, except for the nonce and the timestamp, obviously.
In the headers is also included the oauth_signature, which changes every time and sometimes contains characters that are encoded by OAuthSwift, so that could account for the call working just some of the time (it could work only when the signature doesn't contain a certain character)… but I'm printing out the headers too and I don't see any patterns or any discernible difference between the headers of the calls that work and those of the calls that don't.
So now I don't know what to test anymore… I'm checking the base string and the headers for calls that work and for calls that don't and they look the same… Could anybody think of something else that changes between calls and I should check? I have no idea what could be causing this and I don't know how to debug it.
Thanks in advance,
Daniel
Edit: Very weird… I tried my request with Paw, a Mac REST client, and with Chrome's Postman extension. If I use https I get 404 on my first call, then 201 on the second, then 404 on the third, 201 on the forth and so on. It works every other time. The time it works it doesn't matter if I use http or https, it works as long as there was a failed https request just before.
So I tried doing the same in my app: I added two https calls one after the other… in my app they always return 404.
So it seems like Postman, Paw and OAuthSwift are handling the requests differently. I don't know what could be the difference between those clients… the signature base string seems to be the same for all three, the headers too… so what else could change between them?
In the newer versions of Xcode you can only communicate with a HTTPS server. I expect Google support that so you can change the URL. Or you can edit your Info.plist file.
App Transport Security Settings > Allow Arbitrary Loads > YES
Problem: I am getting an "Invalid Signature" error from Yelp API only from production (running on nginx server in AWS) When I run locally on my localhost:3000, there is no signature error, and everything works fine.
I am using the yelp gem in rails. Here's some code in ruby.:
$client = Yelp::Client.new({
consumer_key: $SL_CONSUMER_KEY,
consumer_secret: $SL_CONSUMER_SECRET,
token: $SL_TOKEN,
token_secret: $SL_TOKEN_SECRET
})
begin
$client.search("Los Angeles")
rescue => error
puts error.message
puts error.inspect
end
error.message prints out: "Signature was invalid"
error.inspect prints out: < Yelp::Error::InvalidSignature: Signature was invalid >
Everything works when I run locally on rails' Webrick server but when I run it in production, I get an "Invalid Signature" error.
Has anyone seen this? I've looked at some relevant posts, but this seems different. Thanks!
This will probably not pertain to most people, but the off chance it could help someone, here it is:
My "time" was effed up on my EC2 instance. So for example, in ruby, Time.now was not printing the actual time. (I think it was off by a few minutes or so).
Anyway, Yelp API requires a oauth_timestamp when you send a request. Of course, then, my request was timing out b/c the time was off.
How did I found this error out?
I just pinged the URL on my browser with the oauth, token, oauth_timestamp, etc. (few more) as query params. The browser spits out the error response in JSON, and it was saying that my request was timing out. When you use the ruby Yelp Client and catch the exception in code, it doesn't spit out the error response in terminal, so it's a bit more difficult to locate the exact root of the error.
How I solved it:
I re-calibrated the time in my ec2 instance by following the directions here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html
Problem is solved. Peace.
Invalid signature error in Yelp API occurs due to two reasons .
First , Either of your four keys i.e consumer_key , consumer_secret_key , Token & Token Secret is invalid . Secondly Parameters passed to Yelp API Function are either invalid or any of those are nil .
Doing scraping I've found that some urls failed. After check the url looked ok in the browser and see in wireshark the remote server was answering with a 200 I've finally found that the url:
http://www.segundamano.es/electronica-barcelona-particulares/galaxy-note-3-mas.htm
was failing with
Net::HTTP::Persistent::Error: too many bad responses after 0 requests on 42319240, last used 1414078471.6468294 seconds ago
More weird is that if you remove a character from the last part, it works. If you add the character in another place, it fails again.
Update 1
The "code"
agent = Mechanize.new
page = agent.get("http://www.segundamano.es/electronica-barcelona-particulares/galaxy-note-3.htm")
Net::HTTP::Persistent::Error: too many bad responses after 0 requests on 41150840, last used 1414079640.353221 seconds ago
This is a network error which normally occurs if you make too many requests to a certain source from the same IP and thus the page takes too long to load. You could try adding a custom timeout to your connection agent, keep the connection alive and ignore bad chunking (potentially bad):
agent = Mechanize.new
agent.keep_alive = true
agent.ignore_bad_chunking = true
agent.open_timeout = 25
agent.read_timeout = 25
page = agent.get("http://www.segundamano.es/electronica-barcelona-particulares/galaxy-note-3.htm")
But that is not giving you a guarantee that the connection will be successfull, it just increases the chances.
It's hard to say why you get the error on one url and not on another. When you remove the 3 you request a different page; one that might be easier for the server to process? My point being: There is nothing wrong with your Mechanize setup but with the response you are getting back.
Agree with Severin, the problem was in the other side. As I can't do anything in the server, I was trying different libs to fetch the data. It was weird that some of them worked and others don't. Trying different setups for mechanize, at the end I've found a good one:
agent = Mechanize.new { |agent|
agent.gzip_enabled = false
}