Max

Check the Actions tab for a banner saying the workflow was disabled. Scheduled workflows get switched off automatically on repositories with no activity for 60 days, and the notification goes to the repo owner by email, where it is read by nobody. I would put money on that being your 23 days.

But the cause almost does not matter, because the fix is the same and it is the lesson everybody learns exactly once: monitor absence, not failure.

The job pings a heartbeat URL as its last successful statement. The monitor alerts when the ping does not arrive inside a window. Failures announce themselves; not running is silent by construction, and no amount of error tracking will ever catch it.

If you insist on a zip, stream it and turn compression off. That runtime gives you a fixed 128 MB heap, and a zip writer that buffers entries or builds the central directory in memory will die exactly where yours is dying. A streaming zip over a TransformStream with store-only entries never holds more than a chunk.

Store-only is also the correct call on the merits - your uploads are already compressed formats, so you are burning CPU to turn 14 GB into 13.8 GB.

The real cost of request mocking is drift. That mocked payment provider response was accurate fourteen months ago. Nothing tells you when it stops being.

If you keep mocks for third parties, generate the fixtures from a recorded real response and re-record on a schedule against a sandbox account. Otherwise you are testing your own memory of an API.

"The database is mocked" and "nothing opens a connection" are different claims, and the gap between them is where your handle is.

Something at module scope opens something at import time, before any mock is relevant. The usual suspects:

• a new Pool() exported from a module you import for one type
• a redis or queue client constructed at the top of a config file
• setInterval in a cache, rate limiter or metrics module
• a tracing or error SDK that starts on import

Stop guessing and ask node:

node --import why-is-node-running/register ./node_modules/vitest/vitest.mjs run

It prints every handle still holding the loop open with the stack that created it. Nine times out of ten it is one line in one file, and it is never the file you suspected.

The other possibility is that you kept things that fit the old you rather than the current you, and the cleanout just made them more visible. If a garment felt off before the cull it will feel worse now that it isn't hiding in a crowd.

Also check your batching. On several platforms a batch is acknowledged as a unit unless you ack messages individually, so one poisoned message drags nine healthy ones back through the retry with it. Drop the batch size to 1 while you are debugging this class of thing and the picture gets much clearer.

Pilling is friction, not washing, and it shows up exactly where two surfaces rub - underarms, sides, seatbelt line, bag strap. Your routine is fine. What's actually driving it is fibre length: cheaper merino is spun from short staple, and short fibre ends work loose and tangle. A sweater at three times the price with the same fibre content can pill dramatically less because the yarn is combed longer staple.

Practical fixes:

• de-pill with a battery fabric shaver, not a comb or tape, and do it on a flat hard surface
• do it after the first two wears, not after it looks bad; the loose fibre gets pulled out and the fabric stabilises
• alternate sweaters instead of wearing one three days running

It slows a lot. The first crop of pills is the short ends near the surface; once those are gone the remaining fibre is anchored in the twist. Shave conservatively: light passes, don't press: and it'll stop being a weekly job after a couple of rounds.

I rolled my own for both stores. Three weeks of evenings, it works, I would not do it again at $2k MRR. It is competent code that produces exactly zero customer value.

The one real benefit is that when something goes wrong I can read the whole thing top to bottom and know what happened. That is worth something. It is not worth three weeks.

For outbound webhooks specifically, failure is not exceptional - it is Tuesday. Customer endpoints go down for hours at a time and it is not your fault or theirs.

What you want:

• retry with real backoff over hours, not three attempts over a minute
• a per-endpoint circuit breaker so one dead customer cannot occupy all your workers
• a page where the customer can see their own failed deliveries, with the response body, and press resend themselves

That last one deletes most of your future support load and is the only one of the three that anybody thanks you for.

Agree with the practical take, but the tailor still has to move the buttons up and the old buttonholes will show as faint marks on some fabrics. On a tweed you'll never see it, on a smooth worsted you might.

Watch the dead tuples. A queue table is the highest-churn table you will ever own, and default autovacuum settings are tuned for tables that are mostly read. Set aggressive autovacuum on that table specifically and archive completed rows out to a history table.

Otherwise you are back here in six months asking why a SELECT over 3,000 live rows takes 400ms, and the answer will be four million dead ones.

Pinch test: standing, grab the fabric at the side of your hip. If you can't pinch about an inch, there isn't enough room there full stop.