GitHub 连数数都出错了
GitHub is having trouble counting things
过去一周，我在 GitHub 上发现了两个严重的 UI 缺陷。首先是 PR 数量统计错误，合并后显示的数字往往比实际列表多，甚至页面上明明只有一条 PR，导航栏却显示两条。其次是分页问题，我在设置 Sentry 时，由于拥有三页的 org 成员列表，却唯独无法访问第二页，Chrome 甚至不允许直接修改弹窗地址栏，只能靠 JavaScript 强制跳转。作为一个使用了 11 年的老用户，看到这些低级错误不禁让人好奇 GitHub 内部究竟发生了什么。
更糟糕的是，正确的计数就赫然显示在这个页面上。
HN 评论区
59- nxc18
GitHub，包括 Enterprise 版本（所以不光是 Azure 的锅），已经变得不可靠、质量低下。
我说它不可靠，是因为我无法指望它准确完成其宣称的功能。我没法信任任何数字，没法信任我调用的操作真的会执行，也没法信任执行操作不会引发神秘的副作用（比如莫名其妙地重新打开我老板的老板在 2017 年关闭且未作解释的 issue）。我想我或许还信任底层的 git 基础设施，但到了这一步，我自己也不确定为什么还这么想。
我说它质量低下，是因为它在随机时刻会异常缓慢，陷入破碎且不一致的 UI 状态，有着令人费解的 UX 设计，让导航变得比本该有的更困难（尤其是新 UI），整体而言，它连 1996 年——或者 2026 年，或者这期间任何时间点——的软件该有的打磨和完成度都达不到。
- zX41ZdbW
一些最古老的 PR 再也找不到了。
例如，当我决定继续我那八年前提交的 PR https://github.com/ClickHouse/ClickHouse/pull/104948 时，我根本看不到它——无论是在搜索中还是翻页浏览时都找不到。
直接链接仍然有效。
- datadrivenangel
脏读（dirty reads）是扩展性差的一个经典症状。最终一致的数据库写入是可以接受的，但如果用户执行了一个操作却看不到操作结果，那看起来就很糟糕。
- huurtehoog
机器寄存器与内存中发生的事、软件所模拟的底层现实、以及呈现给用户的语义化信息之间，存在如此多的间接层，这简直是一场灾难。
软件本可以简单可靠得多。现在有太多的臃肿代码，而这些臃肿本身就是为了解决由臃肿引发的问题。我希望我们能尽早走出这片泥潭。我实在不愿看到整整几代人继续忍受当前的软件状态，而事实上，让软件变得更好的理论理解早在可编程计算机历史的早期就已经产生了。
- Droobfest
昨天我就遇到了这个问题：GitHub API 有时在输出中干脆不列出正在进行的 workflow 运行，哪怕我明确过滤了它：
"api.github.com/repos/{owner}/{repo}/actions/runs?status=in_progress" -> 输出 3 个 workflow 运行
5 秒后 -> 输出 2 个 workflow 运行
再过 5 秒 -> 又输出同样的 3 个 workflow 运行
看来他们对输出的任何类型的一致性或连续性都不作保证，这带来的副作用就是让它完全没法用。