search

vinnymac / PokeNurse

💉 A tool for Pokémon Go to aid in transferring and evolving Pokémon
284 stars 48 forks source link

Status code 52 received from RPC #132

Closed edevnull closed 7 years ago

edevnull commented 8 years ago

When transferring 100+ pokemons in a row I get these errors:

Unhandled rejection Error: operation timed out after 16296 ms, 5 tries with error: Status code 52 received from RPC at /Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird-retry/lib/bluebird-retry.js:102:35 at tryCatcher (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/util.js:16:23) at /Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/catch_filter.js:24:41 at tryCatcher (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/util.js:16:23) at Promise._settlePromiseFromHandler (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/promise.js:504:31) at Promise._settlePromise (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/promise.js:561:18) at Promise._settlePromise0 (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/promise.js:606:10) at Promise._settlePromises (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/promise.js:681:18) at Async._drainQueue (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/async.js:138:16) at Async._drainQueues (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/async.js:148:10) at Immediate.Async.drainQueues (/Users/mrpokemon/Desktop/pokemon/PokeNurse/node_modules/bluebird/js/release/async.js:17:14) at runCallback (timers.js:566:20) at tryOnImmediate (timers.js:546:5) at processImmediate [as _immediateCallback] (timers.js:525:5)

vinnymac commented 8 years ago

Did you build the app yourself? What version are you using? Did you change the default intervals?

Error 52 means that you were rate limited for sending too many requests to the server. According to https://github.com/cyraxx/pogobuf/issues/31 from pogobuf they implemented throttling to prevent this sort of thing from happening. Not sure how reliable that is with our current implementation.

We could do better by placing requests in a kind of queue. Currently everything is dispatched after a timer goes off for each request. We are betting on pogobuf making sure the requests don't hammer the server too much, but it appears that it is failing at doing that. This is something we intended on looking at for #56, which brings into question how that ticket would even work if rate limiting prevents hammering the server. We should probably add some sort of message to inform the user that they are being rate limited as well.

If instead we waited for both the delay and the last request to complete before we move onto another request, then it should work a lot better than it currently does.

In v1.4 we bumped pogobuf so maybe some fixes will come with that, unfortunately this is really hard to test since you need to have a lot of pokemon to throw at the server.

vinnymac commented 7 years ago

We haven't gotten any more reports of this in many months now, and the API usage has changed significantly, we can open another if users start seeing it again.