Stop Hardcoding Your Timeouts
40 points by bahlo
40 points by bahlo
If you actually fucking test timeouts properly, you'll quickly (ahem) realize why they need to be injected instead of hardcoded!
I have a love/hate relationship with those kinds of tests. To avoid making them flaky, I often still have to configure a timeout of a couple of seconds for the test. But given how many things need timeouts, that racks up time quickly!
So I'm always tempted to express the timeout in terms of some sort of system tick instead. Then the timeout can be static and the tick artificially advanced instead. But if the system doesn't already have some sort of tick system that turns into more machinery...
Privileged devs (or the management directing them) not caring about lower specced or poorer users is a legitimate problem, but in this case I don't get it, aren't skills just a bunch of markdown files? What do you need npm for as opposed to just git cloning it (perhaps once to a VPS with faster connection, then using rsync to download it)?
edit: reading further, they do do this
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.
But I'm still confused, can't they just...git exclude or gitignore the skills-lock.json? And why do you even need a lockfile for what is essentially documentation?? And is running an extra git pull really such a hassle?
Skills are, effectively, executable code that happens to be written in human language. The reason to have automation around it is to make it easy for the entire team to use the same set, and the reason to have a lock file is to avoid a supply chain attack where benign/helpful instructions are replaced with malicious ones.
If we were in the habit of pulling docs down locally for humans, you'd want the same behaviours anyway. Humans are also vulnerable to prompt injection attacks. We just call it "phishing" or "social engineering".
(This is not an endorsement of AI usage, but is an endorsement of contextually-appropriate threat modelling.)
Skills are not executable code, though. They're more like a macro for inserting the "code" once into the context. (Calling a skill twice doesn't send theh code again, for example.)
This template can refer to actual code, though! That code would be loaded every time it's run.
https://github.com/vercel-labs/skills/issues/278 (by someone else) quite ridiculous—just skim its first two comments, absurd amounts of unnecessary detail and a preposterous solution, all very obviously slop. All that needed to be said was “cloning repositories can take arbitrarily long, so putting a 60 second timeout is obviously wrong”. The rest is worse than posturing.
Rather like the issue, this article is written in a tedious style which sure looks sloppy, and I disagree with parts of its conclusions.
The thing is, timeouts need to exist. Infinite waits are bad. Hanging processes are bad. I’m not arguing against timeouts.
Since the author won’t, I will.
The skills case shouldn’t have a timeout at all: it’s the wrong place and the wrong thing. You rather want to check if it’s still working, and Git has that handled. The problematic case is if it can get stalled waiting for authentication, and I’m not convinced that can happen in a way that needs to be catered for. If it’s interactive, the user will observe the authentication prompt and so the timeout cutting them off is wrong, and if it’s not interactive then it should fail immediately. I’m inclined to presume it’s slop-style cargo-culting (in which area Chesterton’s fence is an increasingly unreliable rubric).
As for the Docker Gordon case, well, for a human tool I’d just say there shouldn’t be any timeout, it’s obviously dumb, the human will observe if things aren’t working as expected and interrupt it. For AI nonsense, well, this sounds to me like the wrong way to apply a timeout. I would rather expect it to throw an LLM at it and its logs or something to apply judgement like the human would, to see if it seems like it’s not working or stuck and interrupt it. A hard timeout is obviously idiotic, but a timeout at all feels from the wrong era of computing for such a thing.
Cool article but nothing whatsoever to do with disability and shouldn’t be tagged under accessibility even if the domain name happens to look a lot like the abbreviation a11y.
I think an argument could be made that accessibility is broader than being mindful of different needs to do with disability, but also includes accessibility to those who don't have big-tech-hub-tier internet connections. This article is definitely worthwhile but I'm not sure it particularly fits better under any other tags.