Users silenced for "new user typed too fast" not appearing in review queue

On our instance we’ve discovered 2 users who were silenced for “new user typed too fast”, but don’t have any posts appearing in the (historical) review queue, so it seems like there was no way for moderators to ever approve their posts.

One of these users reported it themselves, the other I discovered after some investigation:

I’ve spent some time trying to figure out what went wrong here, but have very little idea. The closest I’ve got is by making a post get stuck in the queue locally, then manually deleting the ReviewableQueuedPost from the db. The end result looks the same as with these two users, so my only theory is that something has been deleting these from the db, or they were never saved in the first place.

Everything I’ve tried is in the issue above, including the Rails commands to fetch this data. I’d be interested to know if there are any users affected by this on Meta.


@eviltrout any ideas here?


I have not seen this before. I looked at the code paths and it seems that if a post/topic passes validation, but the reviewable record does not, this could happen.

Are there any errors in the logs that might indicate why the reviewable record was not saved?

Also just to confirm, you haven’t set a minimum priority to view items right? You confirmed that the ReviewableQueuedPost was not in the database?


Unfortunately we don’t have the logs back from when this last happened (20 May) due to the log rotation in the discourse_docker container (unless I’ve misunderstood how it works).

Yeah they weren’t in the db. I found the affected users with these queries:

total = UserHistory.where(details: "New user typed too fast").pluck(:target_user_id)
alive ={ |x| User.where(id: x).first&.id }.compact{|x| [x, Reviewable.where(created_by_id: x).count]}.filter{|x| x[1] == 0}
=> [[20914, 0], [22425, 0]] # the ids of those users

Let’s keep an eye out and see if we can reproduce it somehow in the future.


This happened again for another user a few days ago, so I still have the logs.

Unfortunately looking through them doesn’t seem to show anything, all I can see is the “you’ve been silenced” post being created by the system user in the sidekiq logs, otherwise there’s nothing - no errors around the timestamp in the production log.

Could we log records that fail to save to see if this is the case?


I looked at the code again and if the reviewable fails validation it’s supposed to attach errors to the result object so that should really be accounted for.

If you wanted to add some logging of those errors that might be useful to debug your situation.


@LeoMcA any news here, is this still an issue?

Just did another query of the db, found two more users affected, but these were in September and October respectively - which we don’t have logs of.

However, since this was happening relatively consistently every 1-2 months, and it’s now been nearly 3 months since the last occurrence, I’m relatively confident this is no longer an issue.


I’m not so sure. I not-rarely come across accounts that have been Silenced and am unable to find any evidence that explains the why.

  • the offending post was in a message I can’t access. (some admin investigation did not support this)

More likely, (based on what remnant Flag Reports I have found) I think it’s a very rare combination something like

  • race condition between “too fast” and Akismet (one works between submit and raw, the other between raw and cooked?)
  • Moderator “rejects” post
  • post gets deleted at the “submit” - as though the post never happened
  • there is no remaining active Flag report
  • the “too fast” that initiated the Silence did not also toggle the state, nor did Akismet, when the Flag was resolved.