Return to Question

This looks like a duplicate of Throttle violation after 300 calls but this one is reported as fixed in 2012.

Today I made ~450 requests with an app key (no oauth token) and suddenly got a 502 response:

throttle_violation : too many requests from this IP, more requests available in 86281 seconds"

Did I do something wrong? The same API key used to work some weeks ago and I made several thousand requests per day without getting any errors.

Update:

Most probably my fault but I'll need to wait another day to confirm it :) I added backoff handling code also to the problematic requests and still failed. Then I noticed that the filter I use only includes .wrapper.total and backoff field is filtered out.

Update 2:

This is still happening after I started using a filter that adds the backOff and the quota_remaining properties.

I created a log file with every request that my app made and the responses. There is not a single backOff tag and the quota_remaining is not 0.

File available here

After 644 requests I suddenly get a throttle violation error without any warning like backoff or something.

I'll create something like a unit test reproducing the issue but it would need some more time since I also need to wait for 24 hours again (or register a new API key but I don't want to abuse).

Update 3:

MCVE available at: https://github.com/vap78/testissue7255

Travis CI integration job that reproduces the issue: https://travis-ci.org/vap78/testissue7255

Additional finding - looks like that the ban is much less than the 86390 seconds returned in the error message. I used the same app key several times this morning and I manage to make ~650 requests every time before I get this error.

Update 4:

I think this is really a bug. I implemented a logic that sleeps for 5 seconds and then retries the request when this error occurs - something similar to the backoff handling which just sleeps for 5 seconds. The retry was successful and the test I implemented passed.

So my best guess is that this error is returned instead of a backoff message for some reason or no backoff is returned in the previous response.

This looks like a duplicate of Throttle violation after 300 calls but this one is reported as fixed in 2012.

Today I made ~450 requests with an app key (no oauth token) and suddenly got a 502 response:

throttle_violation : too many requests from this IP, more requests available in 86281 seconds"

Did I do something wrong? The same API key used to work some weeks ago and I made several thousand requests per day without getting any errors.

Update:

Most probably my fault but I'll need to wait another day to confirm it :) I added backoff handling code also to the problematic requests and still failed. Then I noticed that the filter I use only includes .wrapper.total and backoff field is filtered out.

Update 2:

This is still happening after I started using a filter that adds the backOff and the quota_remaining properties.

I created a log file with every request that my app made and the responses. There is not a single backOff tag and the quota_remaining is not 0.

File available here

After 644 requests I suddenly get a throttle violation error without any warning like backoff or something.

I'll create something like a unit test reproducing the issue but it would need some more time since I also need to wait for 24 hours again (or register a new API key but I don't want to abuse).

Update 3:

MCVE available at: https://github.com/vap78/testissue7255

Travis CI integration job that reproduces the issue: https://travis-ci.org/vap78/testissue7255

Additional finding - looks like that the ban is much less than the 86390 seconds returned in the error message. I used the same app key several times this morning and I manage to make ~650 requests every time before I get this error.

Update 4:

I think this is really a bug. I implemented a logic that sleeps for 5 seconds and then retries the request when this error occurs - something similar to the backoff handling which just sleeps for 5 seconds. The retry was successful and the test I implemented passed.

So my best guess is that this error is returned instead of a backoff message for some reason or no backoff is returned in the previous response.

This looks like a duplicate of Throttle violation after 300 calls but this one is reported as fixed in 2012.

Today I made ~450 requests with an app key (no oauth token) and suddenly got a 502 response:

throttle_violation : too many requests from this IP, more requests available in 86281 seconds"

Did I do something wrong? The same API key used to work some weeks ago and I made several thousand requests per day without getting any errors.

Update:

Most probably my fault but I'll need to wait another day to confirm it :) I added backoff handling code also to the problematic requests and still failed. Then I noticed that the filter I use only includes .wrapper.total and backoff field is filtered out.

Update 2:

This is still happening after I started using a filter that adds the backOff and the quota_remaining properties.

I created a log file with every request that my app made and the responses. There is not a single backOff tag and the quota_remaining is not 0.

File available here

After 644 requests I suddenly get a throttle violation error without any warning like backoff or something.

I'll create something like a unit test reproducing the issue but it would need some more time since I also need to wait for 24 hours again (or register a new API key but I don't want to abuse).

Update 3:

MCVE available at: https://github.com/vap78/testissue7255

Travis CI integration job that reproduces the issue: https://travis-ci.org/vap78/testissue7255

Additional finding - looks like that the ban is much less than the 86390 seconds returned in the error message. I used the same app key several times this morning and I manage to make ~650 requests every time before I get this error.

This looks like a duplicate of Throttle violation after 300 calls but this one is reported as fixed in 2012.

Today I made ~450 requests with an app key (no oauth token) and suddenly got a 502 response:

throttle_violation : too many requests from this IP, more requests available in 86281 seconds"

Did I do something wrong? The same API key used to work some weeks ago and I made several thousand requests per day without getting any errors.

Update:

Most probably my fault but I'll need to wait another day to confirm it :) I added backoff handling code also to the problematic requests and still failed. Then I noticed that the filter I use only includes .wrapper.total and backoff field is filtered out.

Update 2:

This is still happening after I started using a filter that adds the backOff and the quota_remaining properties.

I created a log file with every request that my app made and the responses. There is not a single backOff tag and the quota_remaining is not 0.

File available here

After 644 requests I suddenly get a throttle violation error without any warning like backoff or something.

I'll create something like a unit test reproducing the issue but it would need some more time since I also need to wait for 24 hours again (or register a new API key but I don't want to abuse).

Update 3:

MCVE available at: https://github.com/vap78/testissue7255

Travis CI integration job that reproduces the issue: https://travis-ci.org/vap78/testissue7255

Additional finding - looks like that the ban is much less than the 86390 seconds returned in the error message. I used the same app key several times this morning and I manage to make ~650 requests every time before I get this error.

Update 4:

I think this is really a bug. I implemented a logic that sleeps for 5 seconds and then retries the request when this error occurs - something similar to the backoff handling which just sleeps for 5 seconds. The retry was successful and the test I implemented passed.

So my best guess is that this error is returned instead of a backoff message for some reason or no backoff is returned in the previous response.

This looks like a duplicate of Throttle violation after 300 calls but this one is reported as fixed in 2012.

Today I made ~450 requests with an app key (no oauth token) and suddenly got a 502 response:

throttle_violation : too many requests from this IP, more requests available in 86281 seconds"

Did I do something wrong? The same API key used to work some weeks ago and I made several thousand requests per day without getting any errors.

Update:

Most probably my fault but I'll need to wait another day to confirm it :) I added backoff handling code also to the problematic requests and still failed. Then I noticed that the filter I use only includes .wrapper.total and backoff field is filtered out.

Update 2:

This is still happening after I started using a filter that adds the backOff and the quota_remaining properties.

I created a log file with every request that my app made and the responses. There is not a single backOff tag and the quota_remaining is not 0.

File available here

After 644 requests I suddenly get a throttle violation error without any warning like backoff or something.

I'll create something like a unit test reproducing the issue but it would need some more time since I also need to wait for 24 hours again (or register a new API key but I don't want to abuse).

This looks like a duplicate of Throttle violation after 300 calls but this one is reported as fixed in 2012.

Today I made ~450 requests with an app key (no oauth token) and suddenly got a 502 response:

throttle_violation : too many requests from this IP, more requests available in 86281 seconds"

Did I do something wrong? The same API key used to work some weeks ago and I made several thousand requests per day without getting any errors.

Update:

Most probably my fault but I'll need to wait another day to confirm it :) I added backoff handling code also to the problematic requests and still failed. Then I noticed that the filter I use only includes .wrapper.total and backoff field is filtered out.

Update 2:

This is still happening after I started using a filter that adds the backOff and the quota_remaining properties.

I created a log file with every request that my app made and the responses. There is not a single backOff tag and the quota_remaining is not 0.

File available here

After 644 requests I suddenly get a throttle violation error without any warning like backoff or something.

I'll create something like a unit test reproducing the issue but it would need some more time since I also need to wait for 24 hours again (or register a new API key but I don't want to abuse).

Update 3:

MCVE available at: https://github.com/vap78/testissue7255

Travis CI integration job that reproduces the issue: https://travis-ci.org/vap78/testissue7255

Additional finding - looks like that the ban is much less than the 86390 seconds returned in the error message. I used the same app key several times this morning and I manage to make ~650 requests every time before I get this error.