1月4日事件更新

在1月4日 23:59 UTC，大约40分钟内，deno.land/x 和 deno.land/std 上可用的模块未能正确加载。这是由于一个有缺陷的补丁导致代码被作为 HTML 而不是原始文本提供。这篇文章详细介绍了究竟发生了什么，以及我们正在采取哪些措施来防止将来再次发生这种情况。

所有服务现在都已恢复正常运行。没有数据丢失。我们认真对待此类中断，并对由此造成的影响深感抱歉。

事件时间线

在 23:59 UTC，一项更改 被合并到 deno.land 仓库 中，该更改改进了语言服务器客户端的完成建议。它还包括对代码的重构，该代码确定是否应将原始代码提供给客户端，还是将代码包装在 HTML 中以在浏览器中显示。该代码对运行时客户端的行为做出了不正确的假设，导致 HTML 被提供给运行时客户端，而不是原始代码。

在星期三 00:20 UTC，尝试回滚此逻辑，但部署未成功。

在 00:39 UTC，再次修改代码以直接引用 deno.land 的早期部署作为依赖项，这使得代码能够被部署并恢复服务。

根本原因

deno.land/x 和 deno.land/std 向运行时提供了包装在 HTML 用户界面中的代码，而不是纯代码。代码被重构以提供更符合规范的内容协商，但没有考虑到像 Deno CLI 和 Deno Deploy 这样的运行时客户端在请求中提供 Accept 标头，表明所有内容类型都是可接受的，包括 text/html，因此代码向这些客户端提供了 HTML。

Deno Deploy 缺少“回滚”功能，这意味着无法恢复到之前的提交，并且向前滚动到新的提交（它依赖于托管在 deno.land/x 和 deno.land/std 上的代码）并非易事。

确定客户端获取 HTML 还是纯代码的代码，在测试时使用了关于 Deno CLI 和 Deploy 发送的标头的错误假设。

影响

在 40 分钟的中断期间，对 Deno Deploy 的新部署（依赖于 deno.land/x 或 deno.land/std 的部署）失败，表明该依赖项不是有效的模块。此外，任何对于 deno.land/x 或 deno.land/std 的远程依赖项（如果未在 Deno CLI 中本地缓存）也会失败，表明该依赖项不是有效的模块。

下一步是什么？

我们正在向 deno.land worker 添加测试，以测试此代码的正确行为。我们还在努力向 Deno Deploy 添加一项功能，以允许“回滚”或“恢复”到之前的部署。