There are times when you try to post in a topic, only to get some kind of server error (usually just with a generic “internal server error” message). The problem is, when you try again, you get that “body is too similar” error message instead, and you can’t post without changing the body of your message. Considering that the original message didn’t go through, I don’t think you should get the “body is too similar” error.
AI-generated summary
A user, seanblue, reports a problem where they receive a “body is too similar” error when trying to post again after encountering a server error, even though the original post didn’t go through.
Sam identifies the issue as a problem with storing a key in Redis too early and suggests that rolling back the Redis key can be tricky due to various error conditions. Tgxworld proposes a solution, which is to set the Redis key outside of the transaction when the post has been saved successfully.
Tgxworld later reports that the issue has been fixed in a commit and asks seanblue to provide a backtrace of the log when they encounter the “internal server error”, but seanblue is unclear about what a backtrace of the log is.
This is legit:
We store the key in redis a bit too early which means that a whole slew of errors can mean we never roll back the redis key.
Additionally, looking at post creator there are conditions where it can raise and then this line never hits:
So rolling back this redis set is a bit tricky cause we need to do it for 2 types of conditions (general error OR errors are not blank and the error is not the too similar one)
Additionally this does raise the point on review that #create can technically raise an exception which is a bit inconsistent.
@tgxworld can you add cleaning this up to your list?
I don’t think we need to handle the rolling back of the Redis key at all. We just have to set the redis key outside of the transaction when the post has been saved successfully.
The issue described in this topic is fixed in
https://github.com/discourse/discourse/commit/ec27db78bec4b50a475a5dd830bc0d695bfe66cd
@seanblue If possible, can you provide me with the backtrace of the log when you encounter the “internal server error”?
I’m not sure I understand the question. What do you mean by “backtrace of the log”?