Skip to content
This repository has been archived by the owner on May 20, 2023. It is now read-only.

Triggering abuse detection #26

Closed
bkeepers opened this issue May 9, 2017 · 5 comments · Fixed by #63
Closed

Triggering abuse detection #26

bkeepers opened this issue May 9, 2017 · 5 comments · Fixed by #63

Comments

@bkeepers
Copy link
Contributor

bkeepers commented May 9, 2017

@lee-dohm installed the stale plugin on @atom. I'll need to dig into why this triggered the abuse detection.

https://sentry.io/bkeepers/probot/issues/269777963/

Error: {"message":"You have triggered an abuse detection mechanism and have been temporarily blocked from content creation. Please retry your request again later.","documentation_url":"https://developer.github.com/v3#abuse-rate-limits"}
@bkeepers
Copy link
Contributor Author

This happened again when @hzoo added it to https://github.com/babel/babel.github.io/issues

@bkeepers
Copy link
Contributor Author

Suggestion from @lee-dohm for tracking this down: log rate limiting info after every request/response.

@bkeepers
Copy link
Contributor Author

Another idea that came up while @lee-dohm and I were talking that might help solve this and reduce complaints from end-users is to artificially limit the number of issues that can be marked in one run. For example, if it only marked 5 during each hourly run, then it would avoid abuse issues, and might not seem as aggressive to contributors.

@ungb
Copy link

ungb commented Sep 12, 2017

+1 on the issue #59. I saw a bunch of issues getting closed on atom after 14 days after it got marked as stale but no comment was added.

example:
atom/atom#10831
atom/atom#12308
atom/atom#8880

There's a lot more.

bkeepers added a commit that referenced this issue Sep 27, 2017
In case the app still triggers the abuse detection (#26), this ensures that it tries the abusive activity (commenting) first, and then follows up the non-abusive activity (label).
bkeepers added a commit that referenced this issue Sep 27, 2017
In case the app still triggers the abuse detection (#26), this ensures that it tries the abusive activity (commenting) first, and then follows up the non-abusive activity (label).
@bkeepers
Copy link
Contributor Author

bkeepers commented Jan 2, 2018

jasonrudolph added a commit to jasonrudolph/no-response that referenced this issue Oct 4, 2018
probot#24 describes a problem
where probot/no-response sometimes closes an issue without posting a
comment. We suspect that probot/no-response is attempting to post a
comment but is having the comment rejected by GitHub's abuse prevention
rate limits, similar to the issue experienced by probot/stale in
probot/stale#26.

Following the approach implemented in
probot/stale#64, this commit updates
probot/no-response to first attempt to post the comment saying that it
is closing the issue. If it successfully posts the comment, then it
closes the issue. If an error occurs when posting the comment, it does
not close the issue.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants