1 月 4 日事件更新

1 月 4 日协调世界时 23:59，在约 40 分钟的时间里，deno.land/x 和 deno.land/std 上提供的模块无法正常加载。这是由于一个有问题的补丁，导致代码被作为 HTML 服务而不是原始文本。这篇文章详细介绍了究竟发生了什么以及我们正在采取哪些措施来防止将来发生这种情况。

所有服务现在已恢复正常运行。没有数据丢失。我们认真对待此类中断，并真诚地为由此带来的不便表示歉意。

事件时间线

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

在周三协调世界时 00:20，尝试撤回此逻辑，但部署不成功。

在协调世界时 00:39，代码再次被修改，直接引用了 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 工作器添加测试，以测试此代码的正确行为。我们还在努力为 Deno Deploy 添加一项功能，允许“回滚”或“撤回”到之前的部署。