Four commits across two repos, and a short day by commit count that still managed to contain the most instructive bug I've hit in a while. The through-line, if there is one: things that report a state they haven't verified.
The big piece — bulk actions and how they report partial outcomes — has its own write-up here. This is the rest, plus the one detail from that work that generalises furthest.
1. The toast that was confidently wrong
Bulk lifecycle jobs went out with a named queue on the wrong connection. The queue name was registered, present in the supervisor list, entirely plausible in review. The jobs sat unclaimed in the table while the UI said "3 deployments stopping."
Two things worth carrying out of that:
A queue name registered for Horizon is a Redis queue. Force a job onto the database connection and it never reaches that supervisor — it's watching a different connection. The name being in config is not evidence that anything is listening on it. Local dev made it worse: the listener ran with no --queue flag, so it consumed default only, and a correctly-named queue with nobody on it looks exactly like a healthy one from the browser.
The message is what made it silent. "Stopping" is a claim about the world. The request can't honestly make that claim — all it did was enqueue. It now says "queued to stop — needs a queue worker on the database connection", which costs one clause and turns a mystery into a checklist item.
That went into the project's gotchas file the same afternoon. Traps like this aren't the kind you rediscover; they're the kind you re-introduce, six weeks later, in a different feature. A gotchas doc is cheap insurance against your own future confidence, and it's worth writing the entry while you're still annoyed enough to be specific.
2. An enum defined by the case it doesn't have
Providers grew a stored health status from their last connection check, and the enum has three cases:
enum ProviderHealthStatus: string
{
case Healthy = 'healthy';
case Failed = 'failed';
case Simulated = 'simulated';
}
Two design notes, both of which are about refusing to let distinct situations collapse into one another.
There is deliberately no Unknown case. A provider nobody has ever checked has a null status, and null is what the UI renders as "never checked". Add an Unknown case and a never-checked provider can be stored as though a check ran and came back inconclusive. Those are different facts. Null already means "no value here" perfectly well; inventing an enum case for absence gives absence a way to be written down as presence.
Simulated exists because a fake driver passing is not a pass. If the driver behind a provider is a declared fake, the check exercised nothing real — no socket opened, no credential used. Folding that into Healthy would put a green badge next to a provider that has never been contacted, which is the exact failure mode this whole feature was built to catch. So it's amber, and its description says so plainly: no real driver for this provider type — nothing was contacted.
If you've read the last few of these you'll spot the pattern. Most of my week has been variations on don't let "we didn't check" render as "we checked and it's fine".
Enums with label(), description() and color() keep paying for themselves here, by the way. The moment the UI has to distinguish three shades of "we know something about this", the presentation belongs next to the case, not in a Blade @if ladder that four views each get slightly differently.
3. Bulk actions, briefly
The feature itself: select rows in any listing, act on all of them, and get back a sentence that says what happened and why the rest didn't. Skip reasons are counted individually, so the toast reads "2 not permitted, 1 already stopped" rather than "3 skipped". A run that changed nothing is a warning even when every skip was legitimate — the operator asked for something and got no change, and green means "your thing happened".
Selection is keyed on the public UUID rather than the internal id (these are client-writable properties), resolved through a tenant-scoped query so a UUID from elsewhere doesn't resolve at all, and cleared on any filter, search or page change — a selection that outlives its filter means confirming "delete 12" against a list you can no longer see.
Full write-up in the other post. Six listings now share the trait; the one still to do is the destroy confirmation, which asks you to retype the selected count when the number it should show is the count that will actually be acted on.
4. The design system got an address
Different repo, different kind of work. developers-hub-my/website — the DevHub site — got a persisted design system file and lost a stale planning doc.
The deletion is the more interesting half. DESIGN_PROPOSAL.md had been sitting in the repo describing work that was, by now, mostly already done. A planning document that outlives its plan is worse than no document: it reads as current, and the three items in it that genuinely remain are buried in twenty that don't. Those three moved to a tracked issue along with the tokens it documented, and a longer benchmark study broke out into sixteen individual issues, each with a verified current state and a target state.
The general rule I keep relearning: a document describes how things are; an issue describes work to be done. The moment a doc starts carrying intentions, it acquires an expiry date nobody is watching. Files in a repo are read as fact.
What replaced it is a MASTER.md that's the opposite — purely descriptive. Colour tokens with their CSS variable names, heading and body fonts, the spacing and shadow scales, and a pre-delivery checklist, all under one rule at the top: page-specific files override the master, otherwise the master applies. It codifies a direction the site had already committed to ("Trust & Authority" — navy and blue, WCAG AAA, full light/dark) so page work can be checked against a single source of truth instead of whichever page someone last looked at.
Nothing exotic. The value isn't in the tokens — it's that there's now exactly one place where a disagreement about them gets settled.
What's next
The destroy confirmation showing a count it hasn't verified is, on today's evidence, an offence I'm apparently determined to commit in every corner of the app. That one next.
Top comments (0)