AI揭秘Bug追踪：深度剖析假删除导致文章发布成功却无法打开的问题

2024-02-12 07:11:47

在企业内部的日常运作中，我们常常依赖各种平台进行信息共享和团队协作。其中，内部博客作为一种知识管理和沟通工具，扮演着越来越重要的角色。但正如任何软件系统一样，内部博客平台也并非完美无缺，偶尔会遭遇一些技术故障，影响其正常运行。最近，我们公司就遇到了一个棘手的问题：通过API发布到内部博客的文章，虽然显示发布成功，但用户却无法打开阅读。

这个问题最初是在一次例行测试中发现的。我们的开发团队为了提高文章发布效率，编写了一个Python脚本，利用内部博客提供的API接口，将文章内容自动上传到平台。初期测试一切顺利，文章能够正常发布并显示在博客首页。但随着测试的深入，我们发现部分文章虽然显示发布成功，点击链接后却无法打开，页面提示“文章不存在”或“访问错误”。

面对这个奇怪的现象，我们首先想到的是检查API的返回信息。API的响应数据显示文章发布成功，并返回了相应的文章ID，但同时还附带了一个不太常见的错误代码。通过查询API文档，我们了解到这个错误代码与数据库中文章的“删除”状态有关。

深入调查后，我们发现问题的根源在于API处理文章删除逻辑上的一个瑕疵。当用户通过API删除一篇文章时，API并不会真正地从数据库中删除该文章数据，而是将文章标题修改为“已删除-{原文章标题}”，并在数据库中将文章状态标记为“已删除”。这样做的目的是为了保留文章的历史记录，方便日后恢复或审计。

然而，在发布文章的逻辑中，API会检查文章的删除状态。如果文章被标记为“已删除”，API就会拒绝发布请求，并将错误信息返回给用户。由于API在删除文章时只是修改了标题和状态，并没有真正删除数据，导致在发布新文章时，如果新文章的标题与之前被删除的文章标题相同，API就会误认为这篇文章已经被删除，从而拒绝发布请求，即使文章内容是全新的。

找到问题根源后，我们立即着手制定解决方案。为了避免API在处理文章删除和发布时出现逻辑冲突，我们决定修改API的代码，使其在删除文章时真正地从数据库中删除文章数据，而不是仅仅修改标题和状态。同时，我们还添加了一个新的检查机制，在发布文章之前，先检查数据库中是否存在同名文章，如果存在且状态为“已删除”，则提示用户修改文章标题或选择覆盖原文章。

以下是修改后的API代码片段（示例）：

def delete_article(article_id):
  """
  删除文章
  """
  cursor = db.cursor()
  cursor.execute("DELETE FROM articles WHERE article_id = ?", (article_id,))
  db.commit()

def publish_article(article_title, article_content):
  """
  发布文章
  """
  cursor = db.cursor()
  cursor.execute("SELECT article_id, deleted FROM articles WHERE article_title = ?", (article_title,))
  result = cursor.fetchone()
  if result:
    if result[1]:  # 文章已删除
      raise ValueError("存在同名文章且已被删除，请修改标题或选择覆盖")
    else:
      raise ValueError("已存在同名文章，请修改标题")
  else:
    cursor.execute("INSERT INTO articles (article_title, article_content) VALUES (?, ?)", (article_title, article_content))
    db.commit()