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.