Two dependency advisories, one transitive package, two parents with different declared ranges. Nobody would have noticed if the fix had been done the fast way instead. That's the whole story.
read time ~2 min·meta / infra
At 3:03 in the morning a scheduled agent on a Mac Mini woke up, read two security
advisories, fixed them, wrote a report about what it had done, opened a pull request,
and went back to sleep. I found out about it hours later, from a merge notification.
Nothing was on fire. That is most of the point.
The dependency was `qs`, which nothing in the project depends on directly. It arrives
transitively, through two separate parents, which is the detail that makes this
interesting rather than a changelog entry. Bumping a package you depend on directly is
arithmetic. Bumping one you reach through two parents means checking that the version
you want still satisfies what *both* of those parents said they would accept — and if
it doesn't, you are not doing a version bump anymore, you are doing a negotiation.
Nothing required that check. The advisories named a fixed version. A perfectly
defensible agent reads the advisory, writes the number, runs the tests, and stops. The
tests would have passed. The vulnerability would have been closed. Some months later
somebody would have hit a resolution conflict and spent an afternoon working out where
it came from.
Instead the run pulled up both parents' declared ranges, confirmed the target satisfied
each of them, added a workspace override to lift the transitive version, and only then
installed, typechecked, and tested. The report it left behind cites both advisory IDs
and spells out the dependency path. I read it the way you read a note from a colleague
who was on shift while you were asleep — which is to say, I read it once and believed
it, because it showed its work.
I want to be careful about what I am claiming here. This is not a story about an agent
being clever. The range check is what a careful person does, and it is written down in
the instructions that agent runs on. What I find worth recording is that the careful
version and the lazy version are indistinguishable at the moment of execution. Both
produce a green build. Both close the advisory. The difference only shows up in a
failure that now never happens, which means there is no event to point at, no incident
to write up, and nothing to notice.
That is a genuinely hard thing to build a system around. Absence of a future problem
does not generate a notification. It does not appear in a weekly summary. The entire
observable output of doing this properly is a pull request that looks exactly like the
one you would have gotten from doing it badly.
So this note is the notification. Something worked correctly at three in the morning
while nobody was watching, and it worked correctly in a way that will never announce
itself. Writing it down is the only way it counts.
mood, as rendered while writing this