Oops! An unexpected error occurred - 8D65637D:57B6_A92D900A:01BB_57EFC61A_B

[BarrieP]

Hi,

I'm intermittantly getting this error:

{
	"errors" : [{
			"errorType" : "request",
			"fieldName" : "500",
			"message" : "Oops! An unexpected error occurred. If it continues please report it at help.fitbit.com. Please reference error id: 8D65637D:57B6_A92D900A:01BB_57EFC61A_B92197E0:02DB"
		}
	],
	"success" : false
}

On this occasion it was after token refreshing.  Possibly a few simultaneous refreshes for the same user ( I'm fixing a defect that I have regarding refresh tokens in this scenario ).

This is possibly leaving me with an invalid token, although I've yet to trace my code through when this issue occurs...

Many thanks for any help!

[JeremiahFitbit · Accepted solution]

A 500 error means something went wrong with the Fitbit Web API or the API is defending itself against concurrent refresh token requests with the same token. A 500 error is unlikely to result in a situation where you have an invalid refresh token, as the request failed.

When you get a 500 error refreshing a token, retry the request using an expontential back-off approach.

[ErikFitter]

Hi,

I'm afraid the back-off / retry approach isn't working for me.

We use subscriptions for our app users, and first of all there can and will be a lot of concurrent refresh token requests to the Fitbit api. That is because in many cases Fitbit posts 3-8 subscriptions per user per second! During (async) setting a flag for not processing next subscriptions, the next subscription is already processed, and so on...

When the access token of that user is expired, the resulting refresh token requests will lead to the 500 error. And, more important, backing-off or retrying eventually leads to an invalid refresh token. It looks like the refresh token is somehow invalidated after one or more 500 error.

An example of my node server log:

2017-02-01 16:22:11 default[20170201t113520] Fitbit subscription uid: 5BKVYX
2017-02-01 16:22:11 default[20170201t113520] Fitbit subscription uid: 5BKVYX
2017-02-01 16:22:11 default[20170201t113520] Fitbit subscription uid: 5BKVYX
2017-02-01 16:22:11 default[20170201t113520] Fitbit subscription uid: 5BKVYX
2017-02-01 16:22:11 default[20170201t113520] Token refresh: Oops! An unexpected error occurred. If it continues please report it at help.fitbit.com. Please reference error id: A29E4A0F:7AA2_A92D91CB:01BB_58920B33_1A1F0357:6B9B
2017-02-01 16:22:13 default[20170201t113520] Token refresh: Refresh token invalid: 3375ef98846d6cb5e6fc34b693a9ff93ccd0fee0052e40af239b993e5bf5b27e. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process.

Maybe it's possible to circumvent these problemes by setting flags in a (large) global variable, but that looks like a really ugly solution to me.

My biggest concern: The real problem is Fitbit's api sending so many subscription posts!

This not only leads to invalid refresh tokens, but also to exceeding rate limits, and it also takes a lot of server capacity.

Is there any way to reduce the number of subscription posts?

[BarrieP]

"there can and will be a lot of concurrent refresh token requests to the Fitbit api."

I had exactly this from some Demo/PoC code, but subsequently got rid of it (using NodeJS) with, essentially a singleton object for each user, housing the token, and using Promises such that concurrent calls to refresh the token all re-use the same Promise ( so only one call to Fitbit apis, no matter how many concurrent subscription notifications ).

"Fitbit posts 3-8 subscriptions per user per second! "

I havn't ever seen anything as extreme as that from Fitbit ( only in my unit testing ).  I've since moved on to other projects as of a few months ago... so things might have changed

"The real problem is Fitbit's api sending so many subscription posts!"

 If your code can't handle N concurrent posts, it probably can't 100% reliably handle 2 concurrent posts either ( which doesn't seem so excessive ).  Implying that you need to fix/update/evolve your code to cope with this possibility.

[ErikFitter]

Thank you very much!

The caching of Promises set me on the right track...