Nothing here yet.
Thanks for reading it this closely. You're right that the thread trap cuts both ways, and I think that direction is the more dangerous one. A number that makes you look worse doesn't get questioned, so nobody goes looking. The sweep was the same: rigged in our favor, I'd have caught it; rigged against us, it just sat there. Have you hit the corpus-shape trap yourself? That's the one that still bothers me most, because the number it produced looked completely normal.
It already works roughly that way. Each signal source keeps its own freshness, and "stale" is its own state, never green: the command line shows how long ago a source last reported, and if every source goes stale, the tray fox doesn't show all-clear. Your Prometheus example is the same trap as the journalctl one: the call succeeded, the data didn't arrive.
Not in CI yet. Today the check is done by hand against the code at the release tag, before anything goes on the site. You're right that the default is the easy one to automate, since a test can read the actual Default and compare. Benchmark claims are harder. The failure here wasn't a stale number but a real number attached to the wrong pair, so what I'd want is the measured pair, dataset and dimensions stored next to each number, so a sentence can only cite what was measured.
Thanks Mike, this is right, and sharper than what I wrote. Rotating isn't the erase. Destroying the old key is, and Foxstash can't do that step because it never holds the key. I checked the code this morning, and the honest version is plainer still: Foxstash 0.9 has no rotation path yet. A store opens with one key, and each file's header records its role, store and generation but not which key encrypted it. So today an app can't rotate in place. It would have to rebuild into a new store under a new key and then destroy the old one. Your ordering is the one I'd want once rotation exists (purge, rotate, compact until the fallback checkpoint is under the new key, then destroy the old one), and having the purge report show which key each file uses is how the app would know that last step is safe. I've opened an issue for it, crediting you (https://github.com/Narcoleptic-Fox/foxstash/issues/71), and corrected the paragraph in the post so it doesn't promise a step the library can't do yet.
Sorry for the slow reply, Ege, I missed this one. "Compensation is never hidden in a catch block" is a better one-liner than anything in the post. Caller-owned keys plus a durable record of intent is the right pair: the provider's request ID only protects you from the provider, not from your own retry path. That boundary is what my next post is about: separating replay-safe effects from committed actions so the runtime knows which is which without inferring it from a function name. effects actions and why workflow runtimes need side effect boundaries
