[ SmokeDetector | MS ] Blacklisted website in body, link at end of body, potentially bad ns for domain in body, potentially bad keyword in body, potentially bad keyword in title: Jovian Chile fd by Gettingh on askubuntu.com
@tripleee That pattern looks like it's already caught by Blacklisted website in body and Blacklisted website in answer; append -force if you really want to do that.
[ SmokeDetector | MS ] Url-only title, bad keyword in body, bad keyword in title, blacklisted website in body, blacklisted website in title, +2 more: pilpedia.com/praltrix/ by moeire201 on askubuntu.com
I can't work out whether this is a bug or intended behaviour... Smokey is meant to check all eligible users' flag conditions after an FP, but this feels excessive
[ SmokeDetector | MS ] Bad keyword in body, blacklisted website in body, pattern-matching product name in body, pattern-matching website in body: Rapid Slim Trial Reviews by chkmegyaan on stackoverflow.com
@Glorfindel Yes and no. The real issue is that the blacklisted websites are not bookended by \b, or even better would be that they are required to match the entire domain. Thus, every single entry in blacklisted_websites.txt is actually a pattern match. In this instance, it blacklisted a domain that was not actually intended to be covered by that blacklist entry, or at least was not obviously covered, by the blacklist. I must admit that I had assumed that an entire domain match was required.
termsfeed.com has the #notspam-provisional tag - but has been posted 7 times in the last 20 days - one of which was marked as tp. Might need reviewing?
@MichaelDodd This was caused by two instances of SD being active and responding to commands/feedback. One of those instances is running a version of the code from prior to you being a privileged user. That instance has been put in standby, but will need to have !!/pull run on it when it becomes active again. It became active because metasmoke had some problems which were resolved by deploying a new version, but doing so happened to result in an additional SD instance becoming active.
@Glorfindel It looks like there are multiple posts with fp feedback from the system, for some reason. On some there's both tp/tpu feedback from SD and fp feedback from SD. It should be determined how that happened. In addition, either an admin should go through and invalidate those, or enough users review the post and submit appropriate feedback such that the non-majority feedbacks are automatically invalidated.
A large number of feedback from SD was created when we increased the review threshold from 1 to 2 feedbacks. It was simply duplicating the existing feedback.
Yes, but then why the duplicate feedbacks (both with SD showing more than 1 fp and with SD conflicting with itself; e.g. SD being 2 out of 3 feedbacks)? Assuming the only ways for SD to be assigned the feedback were The Great Duplication™ and deleted users, that would only happen if more than one user was deleted on those posts, or if the deleted user gave feedback after The Great Duplication™, but was later deleted.