Is there a place where I can find complete list of Facebook's error codes?
In my app's stats I have a few 1340004 errors:
Method: dialog:oauth:touch
Error Code: 1340004
Failures: 436
Sampled Method Calls: 1,172
Failure Rate: 37.2%
But what the hell IS that 1340004 error?? The answer is nowhere to be found, and FB's docs got only a small list of payment erros, which are 138**.
Where's the doc for ALL FB error codes?
Thanks.
I noticed that I have the same error:
Method: dialog:oauth:popup
Error Code: 1340004
Failures: 410
Sampled Method Calls: 816
Failure Rate: 50,2%
This data is from 2 days ago, yesterday I reduced Failure Rate to 1'1% and I think that I will not have any failure today. I had a lot of errors with tokens, since 2 days ago I receive longer access_tokens, and I had in my DB a short varchar field for this access_token and the result was truncated access_tokens.
I changed this field yesterday, I suspect that I reduced this error for my fix, but I'm not sure.
Related
While implementing MindbodyApi's soap services particularly ClientServices i continuously got an error code of 201 .. Error code 201 is nested error.
I have been told by mindbody support that this error happens when fields does not match with mindbody online.
Hope it helps :)
I'm trying to use Google's Play Games SDK for iOS. Upon signing my user in and then running one of their straight-forward methods:
[GPGSnapshotMetadata
openWithFileName:saveStoreName
conflictPolicy:GPGSnapshotConflictPolicyRemoteWins
completionHandler:^(GPGSnapshotMetadata *snapshot,
NSString *conflictId,
GPGSnapshotMetadata *conflictingSnapshotBase,
GPGSnapshotMetadata *conflictingSnapshotRemote,
NSError *error) {
NSLog(#"We got here. It must be an actual miracle.");
}];
instead of ever being sent to the completion handler, I get this error:
2014-07-13 22:01:33.700 MegaBits[6931:f007] WARNING: Returning empty data: id not found
2014-07-13 22:01:33.707 MegaBits[6931:f007] VERBOSE: Snapshot cache fully expired: refreshing all.
2014-07-13 22:01:33.892 MegaBits[6931:8d07] VERBOSE: Request had Apiary Status Code: 7
2014-07-13 22:01:33.894 MegaBits[6931:8d07] VERBOSE: Parsed error<http_code: 403, domain: usageLimits, reason: accessNotConfigured>
And those last 2 lines repeat a number of times.
I'm not sure what any of this means. It doesn't appear to be documented anyway, and so far as I can tell, Apiary is an API-generating startup. This error only comes from running this method. Commenting it out results in my code continuing to run smoothly. Apiary also isn't a service I'm using anywhere else.
We also haven't even approached 1% of our quota, so we're not being rate limited.
I'm serializing an array of dictionaries to a string and it seems that it causes issues on the generation of the diff… or something… I've been seeing a lot of these:
AssertMacros: hash <= (~(UniChar)0x00), Hash value has exceeded UniCharMax! file: /Users/…/Pods/Google-Diff-Match-Patch/DiffMatchPatchCFUtilities.c, line: 391
I didn't look very deep but I didn't understood what am I doing wrong…
Also, I'm having a lot of 440 errors that sometimes appear with the error above. How can I handle these errors? Shouldn't the framework send the full object when the 440 pops up?
Thanks!
Error 440 means 'Invalid Diff'. After checking DiffMatchPatch, it seems that the error you're seeing is caused by an excesively large array of diffs (which, in this case, seems to be a Diff Match Patch internal issue).
Please, take a look at this pull request, which already implements the mechanism you're currently working on: https://github.com/Simperium/simperium-ios/pull/121
Specifically, NSArray+Simperium, SPMemberJsonList and SPJsonDiff contain logic to handle DiffMatchPatch.
I am using 140dev Twitter Database Server (PHP) and I am continually getting this error in get_tweet.php. the error I'm getting from the php-error.log file in the Windows/Temp/ directory
PHP Notice: Undefined property: stdClass::$created_at in C:\inetpub\wwwroot\140dev\db\get_tweets.php on line 58
line 58 in get_tweets.php is:
$dateStamp = $this->oDB->telldate($tweet_object->created_at);
I'm not sure why I'm getting this error. There are tons of other instances where $tweet_object->created_at is being used, but I don't get error messages in the php-errors.log file.
Any help would be greatly appreciated!
Okay so I found out that the code I've inherited was not handling all the other messages that occur in the streaming api.
to fix the logged Notice I set an if check before the json processing code:
if(isset($tweet_object->created_at)){
//Do stuff
}
This resolved the Notice messages. It's annoying that I didn't think of a Null check earlier.
*Note: I did try using the property_exists() method in the if statement, but that still displayed the Notice message. Just in case anybody was interested.
APNS returns the following status codes in error response packets when using the enhanced notification format.
0 - No errors encountered
1 - Processing error
2 - Missing device token
3 - Missing topic
4 - Missing payload
5 - Invalid token size
6 - Invalid topic size
7 - Invalid payload size
8 - Invalid token
255 - None (unknown)
I want to know which of these status codes actually indicate that the issue is actually with the device token (ie: I can mark that particular device token in my database as invalid or inactive). I am sure that I can safely do that when I receive a value of 8 as status code. Also, I am pretty sure about what status codes 2, 4, 5 and 7 indicate and when exactly are they returned.
But for the rest of the status codes, I am pretty much in the dark. Apple's website does not contain much information about them either.
Can anybody please enlighten me about each of these status codes in detail. Many thanks in advance.
You're right about the 2, 4, 5, 7, and 8.
0 is good news obviously.
We're left with:
1 - Processing error
3 - Missing topic
6 - Invalid topic size
10 - Shutdown
255 - None (unknown)
1 is a problem on Apple's side, not related to the token.
3 is, according to Apple :
The topic is currently the bundle identifier of the target application on an iOS device.
6 is related to 3.
10 is out of your control but good to handle as well.
And obviously, 255 will not be able to help you define if the token is the problem.
If your goal is to determine a token that was valid at some point and no longer is, you should really refer to the Feedback Service API.