Tag: Systems Engineering

Browse our exclusive articles!

Real Loss or Stale Read? The Night the Records Vanished, and the Dashboard That Lied Both Ways

The system said the records were gone. They really were gone. But the same system routinely reports counts that are wrong by a factor of eight — so how do you know which kind of "gone" you are looking at, before you act on it?

Reconcile Before You Recreate: Making a Bulk Job Safe to Run Twice

Every bulk job gets re-run — after a crash, a false failure, or a nervous operator. Whether that re-run heals the data or doubles it comes down to one question you answer before it starts.

A “Success” Toast Is Not Confirmation: When the UI Lies Both Ways

The message said the record was created. It was not. A different message said the save had failed. That one was already in the database. The interface was wrong in both directions on the same afternoon.

Killing the Process Didn’t Stop the Job: A Runaway Batch and the Orphan That Ran It

I killed the worker, watched it die, and moved on. Twenty-five minutes later a batch I thought I had stopped had quietly finished on its own.

Regex Inline Flags Killed the Field: A Pattern That Compiles Everywhere Else

The question was not broken, not hidden, and not misconfigured. It was disabled — by a two-character prefix that every other language I use accepts without complaint.

Popular

Many-to-One: Why a Mapping Backlog Outgrows Its Target Taxonomy

You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.

The Fix That Didn’t Take: When a Content-Hash Gate Skips Your Code Change

You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.

Your Dedup Scan Is Over-Counting — Because It Forgot What You Already Fixed

The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.

When Your Skills Folder Is a Deploy Target, Not a Drawer

You hardened a skill in the repo, shipped the PR, and the agent kept loading the old one. Or you fixed the live skill by hand, and the versioned copy quietly stayed behind. Same root cause: the copy you run and the copy you version are two different files.

Subscribe