Stop Hardcoding Your Timeouts

Stop Hardcoding Your Timeouts 23 Apr 2026 A developer rant about tools built for one kind of internet Recently, I’ve been losing my mind to hardcoded timeouts. Silent, arbitrary, unconfigurable time limits baked into tools by developers who apparently have never had to wait more than 200ms for anything in their lives. Let me tell you about my week.

停止硬编码你的超时设置 2026年4月23日 一位开发者对那些只为一种互联网环境构建的工具的吐槽。最近，我快被硬编码的超时设置逼疯了。这些静默的、随意的、不可配置的时间限制，被那些显然从未在生活中等待超过200毫秒的开发者植入到了工具中。让我来告诉你我这一周的经历。

The skills Package and the 60-Second Clone Now that coding agents are everywhere, everyone is using skills. The popular way to add them is through packages developed by vercel-labs, and the go-to collection is awesome-copilot, a curated set of skills sitting at 30K+ stars at the time of writing. Except I can’t use it. The repository is too big, and the npx skills installer just chokes and dies. There’s an open issue about this since February #278 on the vercel-labs/skills repo and no one has responded. I’d be happy to send a PR and fix it myself. I just need someone to acknowledge it exists. Is there a configuration option? A —timeout flag? An environment variable? No, there is nothing. The workaround I found? Clone the repo manually first, then install from the local copy. It works, mostly. Except now skills-lock.json points to a path on my machine. My colleagues cannot use it. I also have to update my copy everytime I want update my skills. One workaround creates a lot of other problems.

“skills”包与60秒克隆限制。现在编程代理无处不在，每个人都在使用“skills”。添加它们的流行方式是通过 vercel-labs 开发的包，而首选集合是 awesome-copilot，这是一个在撰写本文时拥有超过3万颗星的精选技能集。但我无法使用它。该仓库太大了，npx skills 安装程序直接卡死并报错。关于这个问题，vercel-labs/skills 仓库中自二月份以来就有一个未解决的议题 #278，但至今无人回应。我很乐意提交 PR 并亲自修复它，我只需要有人确认它的存在。有配置选项吗？有 —timeout 标志吗？有环境变量吗？不，什么都没有。我找到的变通方法是什么？先手动克隆仓库，然后从本地副本安装。这基本能用，但现在 skills-lock.json 指向了我机器上的路径，我的同事无法使用它。而且每次我想更新技能时，都必须更新我的本地副本。一个变通方法引发了许多其他问题。

Docker Gordon and the 2-Minute Death Timer Then came Docker Gordon, the AI-powered debugging assistant baked into Docker. Useful concept. I was stepping through a container build issue, the kind that requires iteration: tweak, rebuild, inspect, repeat. I’ve never used Gordon but when the error manifested itself, it came with a suggestion to try Gordon and so I did. Except Gordon has a hard limit: if your container doesn’t finish building within two minutes, it gives up. The session dies. You start over. A two-minute build might sound like plenty if you’re in a fast environment with warm caches and pulled base images. But if you’re pulling a fresh base image over a slower connection? Debugging a multi-stage build with several heavy layers? Forget it. Gordon has already moved on. There is no way to configure this. No GORDON_TIMEOUT=600 env var. No —build-timeout flag. Nothing. The tool just assumes that two minutes is forever, and if you need more, that’s your problem.

Docker Gordon 与2分钟死亡计时器。接着是 Docker Gordon，这是集成在 Docker 中的人工智能调试助手。概念很有用。我当时正在排查一个容器构建问题，这类问题需要反复迭代：调整、重建、检查、重复。我从未使用过 Gordon，但当错误出现时，它建议尝试使用 Gordon，于是我照做了。但 Gordon 有一个硬性限制：如果你的容器不能在两分钟内完成构建，它就会放弃。会话终止，你得从头再来。如果你处于一个拥有热缓存和已拉取基础镜像的快速环境中，两分钟的构建时间听起来绰绰有余。但如果你是在较慢的网络连接下重新拉取基础镜像呢？调试一个包含多个重型层的多阶段构建呢？算了吧，Gordon 早就放弃了。没有任何配置方法。没有 GORDON_TIMEOUT=600 环境变量，没有 —build-timeout 标志，什么都没有。该工具只是想当然地认为两分钟就是永恒，如果你需要更多时间，那是你自己的问题。

The Pattern That’s Driving Me Crazy Developers often working on fast machines, in offices or homes with gigabit connections, in cities with world-class infrastructure. They build tools with timeout defaults that reflect their own experience. And then they ship those tools to the whole world, with no knobs to turn. The thing is, timeouts need to exist. Infinite waits are bad. Hanging processes are bad. I’m not arguing against timeouts. I’m arguing against unconfigurable timeouts. Against the implicit message that says: if you can’t do this in 60 seconds, your environment is wrong, not my assumption. A timeout should be: A safe default for the common case, Clearly documented so users know it exists, Overridable via a flag, an environment variable, a config file, something. This isn’t hard. It’s respect for your users.

让我抓狂的模式。开发者们通常在快速的机器上工作，在拥有千兆连接的办公室或家中，在基础设施世界一流的城市里。他们构建工具时设置的默认超时时间反映了他们自己的经验，然后将这些工具发布到全世界，却不提供任何调节旋钮。问题在于，超时设置确实需要存在。无限等待是不好的，进程挂起也是不好的。我并不是反对超时，我反对的是不可配置的超时。我反对那种隐含的信息，即：“如果你不能在60秒内完成，那是你的环境有问题，而不是我的假设有问题。”一个超时设置应该是：针对常见情况的安全默认值，清晰的文档记录以便用户知晓其存在，并且可以通过标志、环境变量、配置文件或其他方式进行覆盖。这并不难，这是对用户的尊重。

The World Isn’t a Data Center in Virginia I’m writing this from Cairo. My internet is decent, better than many places in the world. But it’s not 1 Gbps symmetric fiber. It’s not co-located next to an npm registry mirror. A git clone of a large repo takes time. Pulling a Docker image takes time. These are not failures. They are physics. When your tool dies silently after 60 seconds without any way to change that limit, you haven’t built a tool for the world. You’ve built a tool for your office. And this matters more than most developers acknowledge. The global developer community isn’t located in San Francisco or Amsterdam or London. It’s in Lagos, in Karachi, in Cairo. It’s people on 4G connections, on shared broadband, on connections that have real latency because the nearest CDN edge is 50ms away instead of 5. When you assume a fast connection, you’re not making a neutral technical decision. You’re making a statement about whose experience matters.

世界不是弗吉尼亚州的数据中心。我是在开罗写下这些文字的。我的网络还不错，比世界上许多地方都要好。但它不是1 Gbps的对称光纤，也不是与 npm 镜像仓库同处一地。克隆一个大型 git 仓库需要时间，拉取 Docker 镜像也需要时间。这些不是故障，这是物理规律。当你的工具在60秒后静默终止且没有任何方法更改该限制时，你构建的就不是面向世界的工具，而是为你办公室构建的工具。这一点比大多数开发者意识到的更为重要。全球开发者社区并不都位于旧金山、阿姆斯特丹或伦敦。它在拉各斯、卡拉奇、开罗。它是那些使用4G连接、共享宽带的人，是那些因为最近的 CDN 边缘节点距离50毫秒而不是5毫秒而面临真实延迟的人。当你假设每个人都有快速连接时，你做的就不是一个中立的技术决策，而是在宣示谁的体验才重要。

A Note to Tool Authors I don’t think anyone is doing this maliciously. I think it’s a blind spot. Your internet is fast, so a 60-second timeout feels generous. Your machines are powerful, so a 2-minute build window seems like plenty. But please: before you ship a timeout, ask yourself: What if the user is on a slower connection? What if their repo is larger than mine? What if they’re debugging something slow, and that’s the whole point? And then add a config option. One environment variable. One flag. That’s all it takes to go from “this tool doesn’t work for me” to “this tool works for me.” As Bruce Lawson once said: it’s the World Wide Web, not the Wealthy Western Web. The web and the tools we build on top of it are for everyone. Let’s start acting like it.

给工具作者的一点建议。我不认为有人是恶意这样做的，我认为这只是一个盲点。你的网络很快，所以60秒的超时感觉很宽裕；你的机器很强大，所以2分钟的构建窗口看起来绰绰有余。但请在发布超时设置前问问自己：如果用户处于较慢的网络连接中怎么办？如果他们的仓库比我的大怎么办？如果他们正在调试一些缓慢的东西，而这正是问题的关键所在呢？然后，请添加一个配置选项。一个环境变量，一个标志。只需这些，就能让用户从“这个工具对我没用”转变为“这个工具对我很有用”。正如 Bruce Lawson 曾经说过的：这是万维网（World Wide Web），而不是富裕的西方网（Wealthy Western Web）。网络以及我们在此之上构建的工具是属于每个人的。让我们开始付诸行动吧。