@Mast At the moment, I'd say yes, it would get the same FP feedback. The spam, or at least all I've looked at so far, seems to be from 2016 (and then 2020). This post is from 2019, which is more than enough time for a site to go from being spammed to having at least some people finding it and trying to use it. That post is also significantly different from the answers which I've looked at that are part of the astroturfing. I'd have to dig into it even further to see if there are other connections. There are also some mod-private indications that the post is not connected in the same way as the other spam.
The quota_remaining property was not in the API response. Error: no method found with this name at 16:42:13 UTC. Backing off on requests for the next 12 seconds. Previous URL: https://api.stackexchange.com/2.2/questions/425822
weird case there considering the account history https://stackoverflow.com/users/7344216/kayla-sell (That doesn't look like AI output to me, more like the result of some form of mental illness)
@cigien That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command word(s) if you really want to add the pattern you provided.
### KeyError on teward/Osiris at 2022-07-02T19:27:00Z: 'Mak-2022-07-01_SE_API_rollover' File "/home/smokey/SmokeDetector/chatcommunicate.py", line 531, in __call__ result = self.__func__(*processed_args, alias_used=alias_used) File "/home/smokey/SmokeDetector/chatcommands.py", line 1048, in stat stats = GlobalVars.PostScanStat.get(from_stats) File "/home/smokey/SmokeDetector/globalvars.py", line 224, in get stats_set = copy.deepcopy(GlobalVars.PostScanStat.stats[stats_set_key])
### WebSocketTimeoutException on teward/Osiris at 2022-07-02T08:35:08Z: Connection timed out
Well, error handling could certainly be better, but that was already known. OTOH, the up side is that I don't have to go through and individually delete all of the stats records I've locked instead of deleted.
@Mast It looks like the file into which they are pickled upon a normal shutdown ended up corrupted. There was an error when the file was read upon rebooting. As a result, the !!/stat records started over from blank. There's a variety of issues surrounding storing data, rebooting, and crashing. There are a couple of ways which retention of data is handled in SD, neither of which is all that optimal (well, OK, there are actually 3 general ways). Effectively, a significant portion of that should be rewritten to do a better job of minimizing both the number of times nearly identical data is written and the time spent writing, while being more assured that the retention of the data is as resilient as reasonably possible.
