“正文与您最近发布的内容过于相似”
我使用“发送消息给自己”功能作为草稿缓冲区，用于撰写我希望在私下发布后再公开的详细帖子。（主要原因是预览窗格的渲染效果有时与已发布帖子/消息不完全相同，因此我必须发布才能看到最终形式。私下发布也使我能够避免在帖子或主题首次发布后发送电子邮件之前的“编辑窗口”时间限制。）
当我尝试将消息正文粘贴到论坛帖子中时，我收到了“不要用相同的内容骚扰大家” “正文与您最近发布的内容过于相似”的消息。鉴于用户可以删除消息，这似乎是一个不必要的检查。此外，我可能会发送一条消息给某人，然后想将其转换为回复帖子（例如，也许我请他们校对）。
我不是在谈论将消息转换为主题的第一个帖子。我是在谈论向现有主题添加消息。我对 Discourse 数据库结构一无所知，也不知道帖子和消息在结构上可能有多么不同。既然可以剥离消息的“消息”属性并将其伪装成主题，那么似乎也可以进行类似的操作将其转换为回复。
至少，我希望能够在一个帖子中重用消息正文。
可能有一个关于解决方法在此处的提及，但我无法清晰地理解 OP 的流程。
恐怕我不认为这可以被视为一个错误，因为它似乎工作正常。
它由 unique posts mins 管理员设置（默认为 5 分钟）控制，因此如果等待时间造成重大问题，您可以要求管理员减少它？
一如既往地提供了出色的后台见解！
当我回到 discuss.python.org 时，计时器已经过期，我能够发布我最后一条“消息”草稿的正文。如果我没有在第一次重复时被阻止，我就不会在这里发帖。（这不知何故让我想起了“蛇吃自己的尾巴”的表情包。
）
我恐怕不认为这可以被视为一个错误，…
是的，这似乎介于两者之间。此查询是关于为什么在不同平台对象类型中的第一个重复项会首先被阻止。这似乎是权衡一个解决方案以解决另一个问题（尽管是一个较小的问题，因此这种行为的“功能”方面作为防止骚扰发帖和发消息的保护措施是一个净收益）。尽管如此，将帖子正文与消息正文进行比较似乎是不一致的，因此不适用，因为它们的范围如此不同。
…因为它似乎运行正常。
我同意，只要我们将“运行正常”定义为“按预期运行”，并且这是一个设计决定而不是疏忽或意外行为，这两者都属于错误。
我没有在功能（或任何其他地方讨论过）中看到它，并认为这是报告现有非最佳行为的合适场所。
正如任何你不知道如何修复的错误默认会变成“功能”一样，任何碍事的“功能”都可以被视为错误。
等待 unique posts mins 过期甚至是一个变通方法。
我不需要等很久就可以发布消息文本，但这确实会打断流程。也许我是第一个尝试将内容从消息移动到主题回复的用户。
我非常喜欢“pm-as-draft-message”这种方法，而且我也收到过不少这类警告。也许我一直以来都太接受现状了。 我不知道这个工作流程有多受欢迎，所以我们可能属于少数派，但我们可以把它变成一个#功能请求？
或者，在更小的范围内，#用户体验 的方法是在警告消息中包含更多信息（例如，“正文与您最近发布的内容过于相似。请在 %{unique posts mins} 后重试”）。这至少可以强调这是一个基于时间的、只是临时性的限制（尽管可能削弱了其意图？）。
这确实是一个有效且简单（因此非常棒）的改进。我将把它作为一个单独的功能请求提交。
我认为 @codinghorror 一直很喜欢使用私信来处理长草稿，但这并非我们的本意：
在 Discourse 中有一个非常简单的修复/更改：
将其替换为：
def unique_post_key
"unique-post-#{user_id}:topic?.private_message?:#{raw_hash}"
end
再加上一个快速测试，就能解决这个工作流程问题。
我认为这个更改不会影响安全保障。
除非有异议，我将在明天进行此更改。
谢谢你，Sam！
这个修复很快会发布吗？我倾向于在 discuss.python.org 上撰写比这里更长的回复——并且由于讨论内容涉及许多可能因发布未经测试的代码而导致误述和拼写错误的细节，因此我会进行更广泛的校对和修订。
我们有一个正在进行的修复程序：
它应该很快会被合并，并且网站将在未来几周内部署。
在此期间，我建议一个简单的解决方法。在发布草稿时，只需快速进行“空格填充”。
hello world 和
hello world
在 Markdown 中渲染效果相同
hello world。
该主题在 4 天后自动关闭。不再允许回复。