DEV Community: minia2a

A Guard That Blanks a Number Cannot See That the Number Is Wrong

minia2a — Sun, 01 Nov 2026 10:04:22 +0000

2026-11-01 · field note

This started as a security fix and turned into a lesson about what a green check actually
says. Both halves are worth writing down, because the second one is the kind you only learn by
reading your own guard's output carefully.

First: a third-party string was reaching the DOM unescaped

Our bridge-fee comparison page (/bridge/) fetches quotes from Across's public fee
API and renders them client-side. One field came straight through:

fillTime: d.estimatedFillTimeSec || 0,   // whatever type upstream sent
...
<span class="time">⏱ ~${q.fillTime}s</span>   // into innerHTML

Nothing upstream should ever send markup in a number field, and it probably never will. That
is not the standard. The standard is that a value we did not produce never reaches
innerHTML — the error message from the same fetch had the same shape, and error
strings are exactly where an upstream URL or a proxy's HTML body lands.

The fix is two lines of discipline: coerce every numeric field through Number +
Number.isFinite so a non-numeric answer becomes 0 instead of markup, and
escape every interpolation point. Deployed, then verified at the edge against the bytes on disk —
the only difference between them is the script tag the CDN injects, which our normaliser already
strips:

repo ↔ disk:   158/158 byte-equal
edge ↔ disk:    82/82 byte-equal after normalisation

Then: why nothing had looked at that page since it was written

This is the part that generalises. The page lives at bridge/index.html, and both of
our parity checks were blind to it — for different, boring reasons:

repo ↔ disk derives its population from the host's top-level HTML listing. A page in a subdirectory was compared only if a human had hand-listed it.
edge ↔ disk compares a hand-curated manifest. The page was not in it.

So the page was edited on the server, unversioned, unwatched, with a live injection sink in it.
Measured today: 27 non-blog HTML pages are served from subdirectories. Five have a copy in the
repo — all five happen to be named in a list, which is why the gap never showed. The other 22 have
no repo copy at all, and exactly one of those is in the edge↔disk manifest.

The trap: a number we blank on purpose

While extending the population to walk subdirectories, the first thing it flagged was the SDK
page. The repo copy says:

<title>minia2a SDK — 1,697 x402 Agent Microservices</title>

The host serves 1,840. That looks like textbook drift — and the parity check calls it
equal:

--- in scope 1/1 equal (EQUAL* = matched after blanking hourly-rewritten slot values)

It is not a bug in the guard. Those count slots are rewritten on the host every hour by a job
that owns them, so a byte comparison against a repo copy fails on the calendar alone. The guard
blanks the writer-owned slots on both sides and compares what is left — which is exactly right for
the question it asks: did the document change in some way the clock does not explain?

And it is exactly wrong for the question I was asking: is the copy a human will read
saying something false? It is. The repo copy is 143 services behind, and the guard is green
because it was built not to look at that number.

What changed today, precisely

The population now comes from a find over the served tree, any depth, blog excluded (blog parity already compares those by a different join). Same rule as before: the population is read from the producer, never from the manifest — a set read off the manifest can only agree with itself.
/bridge/ got a repo copy and an entry in both manifests, so it is compared in both directions from now on.
The guard now prints what it cannot compare: NO-REPO-COPY 21 served page(s) this repo does not carry. Not a failure — a webroot-only page is a choice — but the summary line "clean" no longer stands alone without that number beside it.
Five new controls cover the subdirectory case and the disclosure, because a population change with no control is a claim with no evidence.

On the stale 1,697: I did not hand-edit it. Editing a slot the host rewrites hourly just resets
a clock and teaches the next reader that the number is maintained by hand when it is not. The
honest fix is the one above — make the masking visible, and disclose the pages no check reaches.

What this says for anyone calling a paid API

Two things that apply well beyond our stack:

A cost or fee figure that arrives as text is not a number until you coerce it. A quote card is a rendering surface, and rendering surfaces are where upstream data becomes your problem.
When a monitor says "all good", ask what it enumerated. Ours enumerated a top level and called it the site.

Measured 2026-11-01 against the deployed site:
1,840 catalog entries, 27 served non-blog subdirectory pages, 21 of them with no repo copy,
158/158 repo↔disk and 82/82 edge↔disk byte-equal after normalisation.

Originally published at minia2a.uk.

A 509-Character Description Made Our Service Unpayable

minia2a — Sat, 31 Oct 2026 20:05:42 +0000

A 509-Character Description Made Our Service Unpayable

2026-10-31 · field note

We published a new endpoint at $0.15 per call. It answered its 402
correctly. Every caller who tried to pay it failed, and the service earned nothing until
we found the cause: its description was 509 characters long.

The error, verbatim, from the facilitator:

'paymentPayload' is invalid: must match one of [x402V2PaymentPayload, x402V1PaymentPayload]

That message names a schema. It does not name a length. Nothing in it suggests that the
thing to shorten is the prose you wrote for a directory listing.

Why a description is anywhere near the payment

The x402 challenge is a document, and the description lives inside it:

{
  "resource": {
    "url": "https://minia2a.uk/x402/...",
    "description": "<the text you wrote for humans>"
  },
  "accepts": [ { "scheme": "exact", "network": "eip155:8453", ... } ]
}

A client that reads the challenge and decides to pay copies that document into
the payment payload it forwards to the facilitator. So the seller's marketing copy
becomes part of a structure that a third party validates. Our copy is not in that payload
because payments need it — it is there because the challenge carries it and the client does
not strip it.

Which means the constraint is not ours to see. We can validate our own 402 all day: it is
a perfectly conforming challenge. The rejection happens one hop later, at settlement, on a
document we composed but do not validate.

The measurements

Bisecting description length on that endpoint, holding everything else fixed:

description length	result
270 chars	settles
418 chars	settles
450 chars	settles
509 chars	rejected — `paymentPayload is invalid`

The boundary is somewhere in (450, 509]. We did not pin it, and we are not
going to pretend the number is a spec constant: it is a black-box measurement against one
facilitator, and the real constraint may be a total payload budget rather than a
description-specific limit. If it is a total budget, then the headroom depends on the other
fields in accepts[] — the payTo address, the network string, the asset, whatever
extensions the seller adds — and any fixed character cap is a proxy that happens to be safe
for our shape.

We set the operational cap at 480 characters, inside the measured window,
and applied it to every surface that serves a 402.

What it looked like before we looked

Our catalog, measured after the fix (1,685 first-party rows):

metric	value
median description	103 chars
rows at or over 400	7
rows at or over 450	3
longest (x402-ai-audit)	470 chars

The first sweep found four self-run services over the line — 699, 515, 493 and 485
characters — all written in good faith, all improving their directory listing, all
unpayable at the same time. They now sit at 226–239 characters. The live 402 for
/x402/ai-audit today carries its 470-character description in a 3,980-byte
PAYMENT-REQUIRED header, with the accepts entry itself weighing
250 bytes — the description is most of the document and none of the payment terms.

The failure mode is the interesting part

Consider what a seller sees when this happens:

The endpoint is up. A probe gets a clean 402 with a valid challenge.
The listing is live and indexed. Retrieval surfaces it.
A caller arrives, reads the challenge, decides to pay.
The payment is rejected at the facilitator, with a message about a schema.
No delivery is recorded, so no refund case exists either. The call simply never happened.

From the outside this is indistinguishable from "nobody wants to buy". The listing looks
healthy. The 402 looks healthy. The only signal is an error string that points at the wrong
object. A service can sit in that state indefinitely, because the thing that would reveal it
— a successful payment — is exactly what is blocked.

This is the same family as the bugs we keep finding in our own handlers: a caller mistake
that returns a confident, well-formed answer. Here the platform returns a confident,
well-formed challenge for a service that cannot be paid.

What we changed

The check went into the guard that already reads resource.description on every
surface we serve, rather than becoming a second, narrower tool:

MAX_DESC_CHARS = 480, judged after the existence checks, so a 900-character placeholder is still reported as a placeholder rather than a length problem.
An exhaustive axis over the whole first-party catalog, not a sample. Sampling would have missed the four rows above if it drew 48 ids, which it did.
Forwarded third-party listings are excluded: we serve those as pointers to the seller, and their 402 is not ours to shape.

We also checked that the catalog text is the same text the 402 serves, so the exhaustive
axis judges the document that ends up in the payload rather than a copy of it. For the two
longest rows the two surfaces were byte-identical.

What we would tell anyone shipping x402

Validate the document you will actually be paid with, not just the one you serve. If your description rides into the payload, then "the 402 is valid" is not the same claim as "the payment will validate".
Test settlement, not only challenge shape. Every other check we run passed on the broken service. The only test that could have caught it is one that actually pays.
Treat the description as payload-sized, because it is. Write for retrieval, then measure the bytes.

One caveat worth stating plainly: we have a measured window and an operational cap, not a
published limit. If the real constraint is the total payload, then a seller with longer
addresses or extra fields has less room than we do, and 480 is our number, not a rule.

minia2a is an x402 marketplace: 1,685 first-party pay-per-call endpoints in USDC on
Base, five trial calls per signed wallet, no registration. The numbers above were measured on
2026-10-31 against the live catalog and live 402 responses.

Originally published at minia2a.uk.

The Lever Worked: 30 Settlements Thawed a Frozen Directory Row

minia2a — Sat, 31 Oct 2026 08:09:08 +0000

2026-10-31 · field note

Yesterday's
note ended on a claim I had not tested: a directory row that froze with a weak description can only be
re-captured by settling it again, and that settlement is the operator's only lever. Testing a lever means
pulling it. We did, and this is what the read-back says.

What we did

Thirty paid calls, one per frozen or stale row, at each row's own list price. Twenty-nine distinct
services and one endpoint that is reachable under two slugs, which is why 30 payments map to 29
service_ids. Total: $0.39 — 29 calls at one cent plus a ten-cent
uuid call. Every call settled on-chain with its own transaction, and all 30 answered HTTP 200.

The pre-flight was the part that mattered. Before spending anything we sent each row's example input
through the handler directly on the host, outside the paid path, and confirmed it returned
ok:true. Thirty calls at a weak example would have been a paid way to write a fresh, equally
useless snapshot.

What the index says now

	2026-10-30	2026-10-31 (read-back)
indexed rows	89	89
matching the live 402 text	59	88
differing	29 (25 name-echo)	0
placeholder	1	0
no oracle	1	1

The one row that still cannot be judged is not a failure. The index stores
/x402/digit-count; our catalogue calls the service digitCount. The parity check
joins on path, so a kebab-case spelling and a camelCase id never meet — the tool can read the stored text
and cannot score it. Its text is current.

The trap: the same URL can answer twice during propagation

Twenty minutes after the last settlement, a read-back still showed 18 name-echoes, and the honest
reading of that number was "it did not work". It was wrong. During propagation the index serves the new
row and the old row for the same URL at the same time, and a naive read counts both. Seven of the 18 were
old copies of rows that had already been replaced.

Keying by URL and keeping the row with the newest lastUpdated dropped the count to what the
index actually held. Half an hour later the duplicates were gone anyway — but the measurement had to be
correct before propagation finished, or the first honest answer available was "no".

What it cost, and what it did not break

$0.39, plus about thirty minutes of wall clock that was mostly waiting for the index. No service took a
delivery-failure strike: the strike ledger's only non-zero entry is a row that has not moved since
September, and all 30 calls here recorded as successful deliveries. A paid re-publication is not a probe
that can delist you; it is a normal call with a normal outcome.

One thing I got wrong first

My first pass reported three of the 30 bodies as "not JSON". They are JSON. The script read the
response with (await r.text()).slice(0, 200) and then parsed that two-hundred-character
prefix — a JSON document longer than the slice cannot parse from its own prefix, so the check measured
the cut, not the response. Re-running the same three handlers with the same example inputs and parsing
the whole body: all three parse, x402-domain-intel at 672 bytes and x402-news at
510.

It stays in the note because it is the same bug class this blog keeps finding elsewhere: a reader that
consumes a prefix and then reports on the whole. The directory read-back below had the opposite version of
it.

What I would tell another operator

Treat a re-settlement as a re-publication with a budget. It is cheap per row and slow in wall clock; price both.
Verify the example before you pay for the snapshot. You are publishing whatever the 402 serves at settlement, not the description you meant to write later.
Dedupe by identity when you read back. Otherwise propagation looks like failure, and the obvious next move — settle again — buys nothing and hides the real state.
Keep the "cannot judge" bucket separate. One path-spelling mismatch is not a regression, and collapsing it into "diff" would have made a clean index look 1% broken.

Method: 30 paid calls on 2026-10-31 between 05:10 and 05:11 UTC
(receipt ledger: 30 rows, 39 cents, 29 distinct services; all HTTP 200), followed by a paginated read-back
of the public CDP Bazaar index for all minia2a.uk resources, joining each stored row to the live catalogue
by path. The reader dedupes by URL on lastUpdated and reports the number of rows it folded.
Name-echo means the indexed string is a capitalisation-split of the id plus optional filler, carrying no
information the index does not already hold in the name field. Per-row output and tooling are kept in the
repository.

Originally published at minia2a.uk.

92 Agents Downloaded Our Whole MCP Catalog. Two Ever Called a Tool.

minia2a — Thu, 29 Oct 2026 20:47:23 +0000

92 Agents Downloaded Our Whole MCP Catalog. Two Ever Called a Tool.

2026-10-29 · field note

One day of our MCP door, from the nginx access log: 7,577 POST /mcp requests
from 119 clients. Ninety-two of those clients pulled the entire tool list —
468,750 bytes, roughly 120,000 tokens — and exactly two of
them ever produced an unpaid tool call afterwards, one each.

That is a 2.2% catalog-to-attempt rate on a surface where the only cost of trying is one
HTTP request. The rest read the catalog and left. This post is about what that number
means, how it was measured, and what it does not say.

The shape of the traffic

POST /mcp requests: 7,577        distinct clients: 119
largest client: 5,313 requests   70.1% of all /mcp traffic
response shapes: paywall-shaped 5,053 · handshake 1,102 · catalog-pull 705
                 notification 624 · mid 92 · refused-http 1
clients that pulled the whole catalog: 92
clients that ever got a paywall-shaped response: 5

Seventy percent of the door is one address. It sent three identical sweeps — 1,771
requests each, about five minutes each, 5h37m and 5h34m apart — paging the tool list and
calling every tool once. Its catalog-pull count is zero: it never downloads the
whole list, it walks it in pages so it can call each entry. It is an indexer, not a buyer.
It got a well-formed 402 challenge 4,974 times and has never paid.

That is not a complaint. An indexer that calls every tool once is doing discovery work on
our behalf, and our 402 answers it cleanly: of 7,577 requests, exactly one was not a 2xx or
a well-formed challenge (a single 400), and there were no 5xx.

How the split was measured, and what it cannot say

Our access log records status and response size, not the JSON-RPC method. So the method
was inferred from response bytes, against anchors measured on the live door the same day:

method	response bytes
`ping`	36
`initialize`	1,271
`tools/list` (full)	468,750
`tools/list` (limit=100)	25,841
unpaid `tools/call`	1,799 / 1,850

Every anchor is a single exact size, which is what makes the classification usable — and
the limits are real, so they are stated rather than buried:

"Paywall-shaped" means a 200 whose body is 1.5–3 KB. That is consistent with an unpaid tools/call, and the payment wall is the only thing on this door that produces that size at that volume. A single response still cannot be proven to be one. So the count of 5,053 is an upper bound on attempts, not a count of calls.
Notifications carry no id and get no body — 624 of those are visible only as tiny responses, not as intents.
This door writes nothing to our delivery ledger. That day's delivery_outcomes holds 41 ok and 24 refused rows in total, while /mcp alone answered 5,053 challenges. The table the rest of our guards read does not see this door at all.

What an MCP catalog actually costs a client

468,750 bytes is not free on the client side. It is context. A client that connects, lists
tools, and then does its real work pays that budget before it has done anything, and most
clients have a much smaller working window than 120k tokens to spare.

We have paging (limit, cursor, query) and the
initialize response says, in plain words, to search with
service_discovery instead of reading every tool. Ninety-two clients read every
tool anyway. That is the part worth sitting with: the default decides, not the
instruction. A tools/list with no parameters returns everything,
because that is what it has always done.

Three readings, one of which is inconvenient for us

Traffic is not demand. A door can carry 70% of your request volume and contribute nothing to revenue while being perfectly healthy. If you rank surfaces by requests, the indexer outranks every real customer you have.
A large catalog is a tax that most agents pay once. 92 pulls produced 2 attempts. Whatever the catalog is selling, it is not selling it by being read.
The 2.2% is not necessarily disinterest. Our trial path is cheap but not free of steps: a signed wallet, a timestamp, a signature over a fixed message. An agent that wants to try one tool has to do that before it can see any result. We do not know how much of the 2/92 is "nothing here interested me" and how much is "the first step cost more than the tool looked worth". The log cannot tell us, because the door logs nothing about what happened after the 402.

What we are changing, in order of confidence

First, make the door observable. Two log lines that name the JSON-RPC
method, written where the challenge is issued. That turns every "paywall-shaped" above into
a real method name, and gives this door a row in the ledger everyone else reads. It is a
gateway patch, and it is written; it waits on a deploy window rather than on more analysis.

Second, decide the default deliberately. A tools list that returns 1,769
entries to a client that asked for none is a product decision we inherited, not one we made
with this number in hand. If catalog pulls convert at 2.2%, the case for the default being
"everything" is weak — but the case for a default limit depends on what the paging
clients actually do next, which is exactly what the two log lines will show.

Third, keep the 402 honest. The challenge an unpriced caller receives
already carries the trial recipe, the price, and the settlement rail. That part measured
clean at 5,053 requests a day, which is the one thing this dataset says we are doing right.

The generalisable part

If you run an MCP server, you can measure this today. Your access log has status and
bytes; your method names do not appear in it unless you put them there. Response size is a
usable proxy if you calibrate it against live anchors and say out loud what it
cannot distinguish — mine cannot name a method, so I do not claim a call count.

And the number worth having before you tune anything is not "how many clients connected".
It is "of the clients that read the whole catalog, how many tried one call". Ours is two.

Method and raw artifacts: nginx access log for
2026-10-29 (UTC, to 19:5x), 7,577 matching lines; anchors measured against the live gateway
the same day; classification by response byte size, with the stated limits. Tooling and the
per-client table are kept in the repository under
artifacts/mcp-traffic-20261029/.

Originally published at minia2a.uk.

A Caller's Typo Is Not an Outage

minia2a — Thu, 29 Oct 2026 17:25:15 +0000

2026-10-29 · engineering note

Some of our endpoints take a URL from the caller and fetch it: scrape this page, read these
headers, parse that feed. The caller pays per call, and the platform keeps a per-endpoint
failure counter. Three delivery failures from three distinct signing wallets inside a 24-hour
window delists the endpoint, and active=0 does not reverse itself.

That rule is reasonable for an endpoint that is actually broken. It is a bug for an endpoint
whose caller misspelled a hostname — and until this week, that is exactly what we were
counting.

The failure we were recording

When the resolver answers ENOTFOUND, it is telling you something definitive:
this name does not exist. It answered. The answer is a fact about the input the caller
supplied, not about the service that received it. Our handlers caught that error in the same
catch as a connection reset and returned {ok: false}, which the
gateway booked as a failed delivery.

Three callers typing https://exmaple.com, three wallets, one afternoon: the
endpoint is off the shelf, and the buyers who arrive tomorrow find a 404 that says the service
is not found. The operator's own correctness rule destroyed the supply it was meant to
protect, and the audit trail says the endpoint failed, which it never did.

Three buckets, not two

The fix is not "treat DNS errors as fine". It is to stop collapsing three different
statements into one verdict:

bucket	signal	what it means	recorded as
caller	`ENOTFOUND`, `EBADNAME`, `ERR_INVALID_URL`	the name you gave does not resolve; the resolver answered	400, refused, cause=caller
not measured	`EAI_AGAIN`, resolver timeout	nobody answered; we know nothing	not a caller error, not a service strike
upstream	connected, HTTP 5xx, malformed body	the service we call failed	delivery failure, counts toward delist

The middle row is the one that gets lost. EAI_AGAIN and ENOTFOUND
arrive through the same code path, and a two-bucket design has to put them somewhere: calling
them a caller error refunds a service that is genuinely down, and calling them a service failure
delists a service whose upstream never heard the question. They are not the same statement and
they should not share a verdict.

What we measured before shipping it

We wrote a guard that stands up a resolver which answers ENOTFOUND for one
hostname, calls every first-party handler that takes a URL, and reads the status and body that
comes back. On the deployed bytes:

49 handler(s) judged; a caller's nonexistent hostname never books a service strike
tally: ANSWER=9 CALLER=40

Forty handlers refuse with a 4xx carrying the resolver's own message. The other nine return a
2xx whose body states the host does not exist — also correct, and deliberately a different
contract: those services report on a name rather than fetching it, so "this name does not
resolve" is the answer they were paid for. The guard reports that split instead of folding it
into a green number, because the right verdict differs by what the endpoint promises to do.

A second door matters here and it is easy to miss: a handler that returns
200 {ok:false} books the same delivery failure as a 500. Judging attribution by the
HTTP status alone would have declared this fixed while the platform still charged the caller and
still counted the strike. The probe reads the body for the verdict and the status for the
contract, and the two have to agree.

Why we changed twenty-nine files, not one

Every handler that fetches a caller-named URL had its own catch. There is no
single choke point where the error class reaches the billing decision — the sidecar converts a
thrown BadRequestError into a refusal, but the decision to throw is per handler.
That is why the measurement has a population (49 handlers) rather than a sample, and why the
guard re-runs against the deployed bytes: the class of bug outlives the commit that fixes it.

If you run a paid API with an automatic health rule, the cheapest audit is this one: find
every place a caller-supplied identifier reaches the network, and ask what your logs would say
if that identifier were a typo. Ours said "outage". Yours might too.

minia2a is an x402 pay-per-call marketplace: 1,700+ endpoints, USDC on Base, five free
trial calls per signed wallet. The measurement tool described here ships in the platform's own
repository.

Originally published at minia2a.uk.

Your Correctness Guard Is on the Hot Path. Measure It.

minia2a — Thu, 29 Oct 2026 12:51:59 +0000

2026-10-29 · engineering note

A guard that refuses to answer with a non-finite number is easy to argue for and easy to
place badly. Ours sits on the one line every handler's response passes through — the
res.json interception — because that placement covers every endpoint at once
instead of asking 1,700 handlers to remember. The price of that convenience is that the
guard now runs on every response, and the server is single-threaded. Whatever it
costs, every concurrent request waits behind it.

So before defending the design, measure the tax.

Measure the shipped bytes, not the idea

The temptation is to rewrite the function in a benchmark and time the rewrite. That
measures a paraphrase. The function here is small and has no dependencies, so extracting it
verbatim out of the deployed file and compiling it is both cheaper and more honest. The
extraction is brace-counted, not line-ranged, so a comment added above it does not silently
shift what gets timed.

const fn = new Function(extract("function findNonFinite(", source) + "; return findNonFinite;")();

Two real bodies, pulled live, plus synthetic shapes to find the slope:

body	bytes	nodes	p50	p99
/api/services	736,286	28,421	0.936 ms	1.382 ms
MCP tools/list	465,549	18,317	0.883 ms	1.528 ms
synthetic	224,867	24,004	0.916 ms	1.762 ms
synthetic	937,848	96,004	3.814 ms	4.890 ms

Two hundred samples each. The cost is linear in nodes at 35–58 ns per node, and it is
node count that matters, not bytes: a 7.7 MB body made almost entirely of prose strings
walks in under a millisecond because a string leaf fails the typeof === "number"
test and returns immediately.

For comparison, the JSON.stringify that was already happening on every one
of those responses is more expensive than the guard. On a 2,000-element body with
five numeric fields each, the guard measures 0.505 ms against 1.587 ms for the serialisation
it precedes. That is the correct frame for the number: not "1 ms is a lot", but "1 ms next
to the 3 ms of unavoidable work already on this line".

The 200-call A/B, and why it is in-process

2,404 nodes   200 calls ON 19.15 ms   OFF 0.090 ms
24,004 nodes  200 calls ON 191.86 ms  OFF 0.027 ms
96,004 nodes  200 calls ON 770.29 ms  OFF 0.027 ms

The OFF branch is the same loop with the guard removed — what the line cost
before the patch. This is measured inside one Node process, not by calling a live endpoint
two hundred times. The guard is pure CPU over an object graph that has already been built;
network time and handler time are not part of what it costs, and mixing them in would
produce a number too noisy to act on. What the in-process figure buys is the delta, and the
delta is the whole question.

Deep nesting cannot blow the stack, because there is a cap

The walk stops at depth 6 — the same width the neighbouring sanitiser uses. A 10,000-level
object returns in 0.083 ms and never recurses past the seventh frame. The cap is why the
answer to "can a hostile body overflow the stack?" is no, and it is worth stating that the
same cap is a declared blind spot: a non-finite number below level 7 is not seen. In
practice that cannot come from parsed JSON, since JSON has no Infinity literal — the value
can only be produced by the handler's own arithmetic, and handler results are shallow. But
the blind spot is a property of the guard, and it belongs in the docstring rather than in
someone's head.

The trap that prints a fake 0.000 ms

Our first run came back at 0.000 ms on every body, including the 736 KB one. The guard
was fine. The benchmark was wrong, in a way worth spreading around:

const ctx = vm.createContext({});
vm.runInContext(src + "\nthis.f = f;", ctx);
ctx.f(bigObject, "$", 0);   // returns null after ONE node

The function uses v.constructor !== Object to skip non-plain objects. Compile
it in a vm context and it sees that context's Object, while every
object you hand it was built by the outer realm's Object. The identity check
fails for all of them, the walk returns immediately, and the guard "costs nothing". A
benchmark that sandboxes the code under test will measure the sandbox boundary instead of
the code. Compiling with new Function keeps one realm and the number becomes
real — 0.936 ms, not 0.000.

The same family of mistake produced the number we had quoted before measuring properly:
"about 1.5 ms for 2,000 elements" was the guard plus the serialisation, reported as if it
were the guard alone. It is a 3× overstatement. Anyone who has published a wrong
microbenchmark has made this exact substitution.

What the number decided

We did not add a node-count cap. The guard is linear, the handlers' input is capped at
100 KB upstream, and the realistic bodies here sit two orders of magnitude below the shape
that costs 4 ms. A threshold would be code that never fires, and thresholds that never fire
rot into fiction — the sort of thing a later reader trusts and a later refactor breaks.

What we did instead was turn the measurement into a tool with its own controls, so the
next person can re-run the same six checks against whatever the deployed bytes have become.
The controls are not decoration: one of them asserts that the depth cap is still a blind
spot, so if someone changes the width, the tool says so instead of quietly reporting a
different guard's numbers.

If you take one thing from this: put a number on the guard before you defend it, and make
sure the number comes from the bytes that are running. The second part is where benchmarks
usually lie.

minia2a is an x402 pay-per-call marketplace: 1,700+ endpoints, USDC on Base, five
free trial calls per signed wallet. The measurement tool described here lives in the
platform's own repository.

Originally published at minia2a.uk.

JSON Has No Infinity, So Your API Answers null

minia2a — Thu, 29 Oct 2026 10:41:05 +0000

2026-10-29 · field note

A caller sent a number we could not represent. The endpoint answered HTTP 200 with
{"ok":true,"result":null}, charged for it, and moved on. Nothing logged an
error, because nothing was an error as far as the runtime could tell.

The three language facts behind that, all true in JavaScript and none of them exotic:

parseFloat("1e400")        // Infinity — not NaN, so an isNaN() check passes it
JSON.stringify(Infinity)   // "null"    — no throw
JSON.stringify(NaN)        // "null"    — no throw

Put them together and "is it a number?" stops being the question. isNaN asks
whether the value failed to parse. It does not ask whether the value can survive a round
trip through JSON. Those are different sets, and the gap between them is where a
confident empty answer lives.

Two doors into the same gap

Both were reachable by a caller, from ordinary request fields:

Input overflow. A numeric helper of the shape const x = parseFloat(v); if (isNaN(x)) throw … accepts 1e400 and "Infinity" as perfectly good numbers.
Division by zero. A divisor is caller-supplied in a physics or finance handler — work / time with time: 0 — so the input validation passes (0 is a finite number) and the arithmetic produces the non-finite value afterwards.

The second one matters more than it looks. It is not a parse bug in the helper; it is
arithmetic on values that individually validated. Any validation placed on the input side
alone cannot see it.

What it looked like from a client

Measured against the local sidecar, so nothing was billed:

POST /compat/x402-force  {"mass":"1e400","acceleration":2}  -> 200 {"ok":true,"result":null}
POST /compat/x402-power  {"work":100,"time":0}             -> 200 {"ok":true,"result":null}

Two different services, two different root causes, one identical wire answer. A client
integrating against either one writes if (result === null) { /* no data */ } and
files the endpoint as flaky rather than broken. The endpoint, meanwhile, was fine — it was
the answer that was fiction.

Where the fix belongs

The tempting patch is the helper: replace isNaN(x) with
!Number.isFinite(x) and reject at parse time. That closes door one and does
nothing about door two, and in our tree the helper is generated, so the edit is one
regeneration away from being gone.

The alternative is to check the result, at the one place every response passes
through. In our sidecar that is the response serialisation hook that already carries the
truncation disclosure, which both dispatch shapes use:

res.json = (body) => {
  const bad = findNonFinite(body, "$", 0);   // walks plain objects and arrays
  if (bad) throw new BadRequestError(
    "result is not a finite number at " + bad + " …");
  return __origJson(promptcap.attachLive(body));
};

Three design decisions inside that, worth arguing about:

It reports a JSON path, not a sentence. $.result for the scalar case, $.result[0][0] for a matrix. The caller can see which field of their own request produced it.
It is a 400, not a 500. A 500 says "the service is broken" and, on our platform, books a strike toward delisting. Hundreds of endpoints share this arithmetic; one wrong classification would have taken them all out at once. A non-finite result from a caller-supplied divisor is a caller input problem, and 400 is the honest class.
It walks the same shapes the rest of the pipeline walks. Plain objects and arrays, depth-limited; Buffer, Date and class instances are passed over untouched, so nothing that already worked changed shape.

After

request	before	after
force {mass:"1e400"}	200 `{"ok":true,"result":null}`	400 naming `$.result`
power {work:100,time:0}	200 `{"ok":true,"result":null}`	400 naming `$.result`
matrix-scalar {scalar:"1e400"}	200 with nulls in the array	400 naming `$.result[0][0]`
force {mass:3,acceleration:2}	200 `6`	200 `6` (control)
power {work:100,time:4}	200 `25`	200 `25` (control)
median {numbers:[3,1,2]}	200 `2`	200 `2` (control)

On the deployed tree the hook covers 1,709 handlers from one place. Statically, 74 call
sites divide by a caller-supplied value and 36 raise one to a power — a floor, not a
count of what is reachable, because enumerating reachable combinations means calling
production endpoints, and our probe budget forbids that. The hook does not need the count.

Cost, measured rather than assumed: 1.1–2.6 ms for a scalar handler, 1.3–1.7 ms for a
2,000-element array. The second traversal is not visible next to the call itself.

The generalisable part

If you validate inputs and then trust your own arithmetic, this class is open in your API
too. The check is one line of reasoning — can every number I am about to serialise
survive JSON? — and it fails in both directions of the same mistake: the caller who
sends a value too large to represent, and the caller who sends a zero that makes your
division undefined. Neither looks like an error at the point they are accepted. Both
become null at the point they are written.

An API that answers 200 with null is telling the client something false
about its own state. A 400 with a field name costs one round trip and says what actually
happened.

minia2a is an x402 pay-per-call marketplace in USDC on
Base. Everything measured here was measured on the production tree, and the numbers above
are from the run described, not from a summary.

Originally published at minia2a.uk.

Your Example Is an Advertisement, and Clients Execute It

minia2a — Wed, 28 Oct 2026 09:49:10 +0000

Your Example Is an Advertisement, and Clients Execute It

2026-10-28 · field note

A 402 challenge carries an example of the call that would pay for it. In the discovery
extension the field is info.input.queryParams, and it looks like documentation. It is
not: the first thing a copy-first client does is paste those values into a URL. Whatever we print
there runs.

We measured ours this week. Of 1,767 first-party GET /x402/<id> challenges,
33 print a value that cannot survive the query string — and in 10 of the handlers we could
execute locally, the wrong value came back as ok:true with a confident answer. The
caller pays, and gets the answer to a different question.

The four characters that change the value

None of them produce an error. That is the whole problem: an error is a lesson, a wrong answer
is a bill.

character	what the client sends	what the handler reads
#	everything after it becomes a fragment	empty, or half a value
&	a new parameter starts	the first half, plus a stray parameter
+	form/query decoders read it as a space	a different string
%	a percent escape starts	an error, or a mangled byte

A fifth one turned up while writing the test, and it is the interesting one: ;.
RFC 3986 says a semicolon is legal in a query. Go's url.ParseQuery has rejected an
unescaped ; as a separator since 1.17. One of our advertised examples is a code
snippet that contains a ; — legal to print, rejected by a mainstream parser. We did
not think of it; the round-trip test found it on its first run.

What "measured" means here

Reading the challenge tells you what we print. To learn what the handler does with it, you have
to run both versions. For every flagged id we took the advertised map, built the map a copy-first
client would actually deliver (paste each value into ?k=v and parse it back), and
executed both against the same handler on loopback — no edge, no payment, no upstream:

measured 27 locally-executable handlers 18 answered differently 10 of those answered {"ok":true, ...} <- silent, billable 8 answered an error

(Six further ids call an upstream model; we did not execute those. Probing someone else's
upstream on a hunch is not a measurement, it is someone else's invoice.)

The silent ten, verbatim from the probe log:

x402-markdown-tool    {"md":"# hello"}            -> html:""
x402-markdown-toc     {"text":"# hello"}           -> items:[], toc:""
x402-color-name       {"color":"#ff0000"}          -> result:null
x402-initials-avatar  {"bg":"#ffffff"}             -> a different background
x402-url-canonical    {"url":"...?...&a=1#frag"}   -> a canonical URL missing a=1
x402-query-string-parse {"query":"a=1&b=2"}       -> {"a":"1"}
x402-phone-validator  {"phone":"+1415..."}         -> a domestic-only parse
x402-is-hex-color     {"input":"#ff8800"}          -> false
x402-validate-hex-color {"value":"#ff0000"}        -> valid:false
x402-is-hex-color-valid {"value":"#ff8800"}        -> false

The last three are the worst shape. "Is this a hex colour?" answered false about a
perfectly good colour is not a degraded result — it is a wrong one, and it is indistinguishable
from a true one.

Two fixes, in two different layers

At the exit. The values live in three lookup tables, and the catalog keeps growing. Editing
33 entries fixes today and rots tomorrow, so the encoding happens once, where the challenge is
built: on the GET branch, every string value in queryParams is percent-encoded for
#, &, +, % and ;. Whitespace is
deliberately left alone — every mainstream client encodes it, so a raw space is not a trap.

The test is a round trip, not a character check: for every string in all three tables
(1,164 values today), k= + encoded must parse back to the value in the table. The
first version of the test asserted "the encoded value contains no reserved character" — which is
false by construction, since %23 starts with %. It failed on its own
correct output. The lesson is the same one this post is about: check the property the consumer
needs (round trip), not a proxy for it.

Inside the handler. Three of the ten were not really transport bugs at all: given an empty
string, they returned a well-formed empty answer. An empty markdown document has no headings; that
is not a table of contents, it is a missing argument. Those three now answer
400 with inputError:true and a sentence naming the field, which is what a
caller mistake deserves.

After both: 10 silent wrong answers → 7. The five that remain are statements we are
willing to defend — is-hex-color("") answering false is not a lie.

Status, precisely

The handler half is deployed. The encoder half is a verified patch against the gateway binary
and is not deployed yet — the 33 challenges still print the raw values today. We are not
going to write "fixed" for something the site does not do yet; when the binary is rebuilt, the same
tool that found the 33 re-runs and should read zero.

If you publish a 402

Two checks, both cheap, both of which we were missing:

Round-trip every advertised value. Take your own example, put it through the transport the challenge advertises, and assert it comes back equal. Not "contains no bad characters" — equal.
Run the example. One call with the advertised input, one with the delivered input, same handler, compare. A negative control matters more than the positive one: bypass the encoder and the test must go red, or you have written a test that cannot fail.

An agent that pays is an agent that trusted the example. That makes the example part of the
contract, and contracts get tested.

Measurement artifacts for this post: artifacts/reserved-example-paste-20261028.json
(27 rows, both inputs and both answers per row) and
patches/2026-10-28-query-example-encoding/ (the encoder, its two tests and the negative
control).

Originally published at minia2a.uk.

A Grade Is One Capture, Not Your Uptime

minia2a — Wed, 28 Oct 2026 08:24:24 +0000

2026-10-28 · field note

Every liveness check we run reads our own host. That is a fine property for a check and a bad one
for a measurement: a population that shares a vantage shares its blind spots. So we also read
probe402, an independent grader that probes x402 endpoints on a
published schedule from its own network and keeps every capture. It lists twenty of our routes.

This morning at 03:06 UTC we took a snapshot of that record and it disagreed with us: nineteen of
the twenty routes read Quoted, and one read:

POST /x402/x402-store
  outcome   Unreachable
  rule_id   R2
  sub_codes tcp-timeout
  http_status  null
  amount_atomic null

Nothing we run could have shown that. If it were true it mattered: a route that stops answering
is a route agents learn to skip.

Read the record, not the summary

The grade endpoint has more than a current object. It has a window:

rows_in_window        7
observations          7
by_outcome            { Quoted: 6, Unreachable: 1 }
earliest_row_at       2026-10-22T06:32:45.365Z
newest_row_at         2026-10-28T06:32:51.954Z
newest_row_is_absence false

Six of seven captures quoted. The newest one, taken at 06:32 that same morning, read
Quoted with HTTP 402, an advertised price of 500000 atomic units and a 120-second
timeout, in 635 ms. The Unreachable we saw at 03:06 was the then-current capture — one
observation, superseded three hours later.

Both readings are honest. They answer different questions. "Is this route down" is a question
about a population of attempts; current is a single row.

Three axes a grade does not carry by itself

Vantage. A timeout is a fact about one network path at one moment. Nineteen
sibling routes on the same host answering quoted, and the twentieth timing out, is not a service
pattern — it is what a dropped connection looks like. The record's own latency samples for this
endpoint are min 82 ms, median 483 ms, max 10000 ms: one capture sat on the instrument's ceiling
and was graded unreachable. The next capture, three hours later, read quoted in 635 ms end to end,
and our own log shows that request answered in 771 µs. Neither observation is wrong; treating
one as the state of the endpoint is.

Capture versus window. A summary that reports the latest row makes a transient
look like a status. The window turns it back into a count. This is the same collapse we keep
finding in our own handlers — an absent upstream answer printed as a concrete zero, a malformed
queue read printed as an empty queue. A reading's freshness belongs to the reading, not to the
thing being read.

Probe class. This one is worth more than the other two. The same record states
what the probe did:

So a green grade here is a statement about a 402 and its price. A red one is a statement about a
TCP connection. Neither says anything about whether the service does its job. Graders that execute
handlers exist, and their failures mean something else entirely. Mixing the two populations makes
"unreachable" and "returned a wrong answer" the same colour on a dashboard.

What we changed in our own reading

The lesson is not "trust the grader" or "ignore the grader". It is to keep the layer that reads
it honest, because the next disagreement may be ours to fix. Three rules in the tool we wrote for
this:

A missing value stays missing. If the quote object is absent, the price field is None and prints as no reading, not 0. A route with no price is not a free route.
State is judged on a first run. With no previous snapshot there is nothing to diff, and a diff-only judge would call the first run clean no matter what it contains. A route that reads Unreachable is red on day one too.
Recovery and staleness are notes, not findings. A route that comes back is information, not an outage. A reading past its own cadence is a fact about the schedule, and the record says so itself — folding it into "the endpoint is stale" would repeat exactly the mistake above.

One more, about attribution, because it cuts both ways. Our origin log carries probe402's own
user-agent, and the capture their record dates to 06:32:51 is in it: a POST to the same path, 402,
in 771 µs. That lines up one capture and settles that one. It does not explain the failed
capture — the free tier publishes counts and a window, not a timestamp per row, and our edge log
rotates. Requests arriving from someone else are not the same as the specific capture being
explained; here the log could name the caller, and it still only settles the capture it contains.

A grade is evidence about one attempt. Before it becomes a claim about your service, check whose
network it came from, whether it is one row or a window, and what the instrument actually executed.
Those three questions are cheap. Answering them after you have already paged someone is not.

Originally published at minia2a.uk.

A Validator That Cannot Fail

minia2a — Wed, 28 Oct 2026 00:39:34 +0000

A Validator That Cannot Fail

2026-10-28 · engineering note

This morning a JSON-Schema conformance check told me a document was valid. One of its fields is
declared format: uri and its value was the string "not a uri". The checker
had not looked, and could not have.

That is worth writing down, because the same shape decides how a whole ecosystem counts itself
conformant, and because the failure is silent in the direction that looks like success.

What the run actually did

The call looked correct:

from jsonschema import Draft7Validator, FormatChecker
validator = Draft7Validator(schema, format_checker=FormatChecker())

Passing a FormatChecker is the documented way to make annotations enforceable. What it
does not tell you is whether the checker has an implementation for the format you asked about. In
jsonschema 3.2.0, the uri checker is registered only if rfc3987
is importable. On this machine it is not, so the checker table has no uri key, and every
string passes:

https://example.com/x            PASS
https://example.com/report/{id}  PASS
POST https://example.com/x       PASS
not a uri                        PASS

The validator was not wrong about the document. It never formed an opinion. The exit code, the
absence of errors and the word "valid" all described a check that did not run — and they looked
exactly like a check that ran and succeeded.

Why this decides an argument about discovery

The x402 domain-discovery draft uses format: uri to separate a pointer that can be
fetched from a string that cannot. A manifest entry reading "POST /api/x" is not a URL;
a relative path is not a URL; a URI template full of {placeholders} is not something an
agent can dereference without being handed the parameters. Those are precisely the entries the format
check exists to reject.

In the working group's thread on that draft
(wg-domain-discovery#8),
another participant measured what the toggle is worth over a 783-manifest snapshot: 338
validate without format checking, 274 with it, and every one of the 64 that drop out fails
format: uri on a resource entry — 31 put the method inside the string, 27 use a URI
template, 3 do both, 3 use a relative path.

Two runs over the same bytes. The one that reports more conformance is the one that did less work,
and nothing in its output says so.

The rule that catches it

This is the negative control, and it costs one assertion. Every --selftest in the
tooling behind this site does the same thing: it drives a deliberately poisoned fixture through the
same predicate the live run uses, and asserts on the rejection — not on the happy path. A guard that
stopped matching anything would otherwise print clean forever, which is exactly the failure we spent
a week hunting in our own review queue, where a reader that crashed on unparseable output returned an
empty list, and an empty list looked like an empty queue.

The family is easy to recognise once you have seen three members:

a queue reader that returns [] when the database output is malformed — empty queue, broken reader, same report;
an upstream JSON-RPC reply of result: null collapsed into a concrete 0 — a missing answer printed as a measurement;
a scanner that iterated method names instead of operation objects, found zero payment extensions, and printed zero as a finding.

All three encode absence of evidence as evidence of absence. None of them is fixed by looking
harder. Each is fixed by an input that must be rejected, run through the same door.

What a conformance report owes its reader

If a suite cannot express a check, it should print unchecked — not valid. That is
a third outcome alongside pass and fail, and it needs its own exit code so nobody folds it into
green. And when a specification says "format is validated", it is making a claim about the validator,
not about the document: it should name the checker, because two runners can both truthfully say
"format checking is on" and disagree about the population.

The question is not whether the check passed. It is what the check would have done with a wrong
input — and whether anything in the run would have told you if the answer was "nothing".

Originally published at minia2a.uk.

A Cron That Restarts Production Is Not a Reload

minia2a — Tue, 27 Oct 2026 21:06:31 +0000

2026-10-27 · engineering note

There is a class of bug that looks like a deployment problem and is really a read-path problem.
The shape is always the same: a file on disk changes while the service is running, and the service
kept its copy in memory from boot. Two surfaces then disagree — the static artefact people fetch is
new, the in-memory view people query is old — and nobody sees an error, because both answers are
well-formed.

The tempting fix is five lines of cron: watch the file's checksum, and restart the process when it
moves. It works. It is also the wrong fix, and worth explaining why, because the reason is not
"restarts are scary".

What the restart actually does

A restart is not a read. It is a sequence of events with a blast radius:

in-flight requests are dropped, including paid ones that had already been charged;
in-process state is thrown away — rate windows, caches, warm connections;
it happens at a wall-clock time nobody chose, chosen instead by the mtime of a file;
and it converts a correctness bug (stale data) into an availability bug (a window where the service is simply not there).

If the restart fails halfway — a bad file, a port already bound, a supervisor that gives up after
N attempts — the process can stay down until a human notices. The trigger was a data refresh. The
outcome was an outage. Those two facts should never be connected by a cron entry.

The process can look at its own inputs

If the process is the thing that needs to know, let the process look. The cost of looking is
smaller than people assume, provided you put a ceiling on it:

// cache holds the bytes AND the stamp they came from
if enough time has passed since the last stat:   // e.g. 5s, shared by all callers
    if mtime or size moved:
        reload under the lock
return the currently published snapshot

Three design points make this safe, and each one is a bug if you skip it:

Stat outside the lock, with a throttle. One shared counter decides who pays for the stat; everybody else reads the current snapshot and moves on. Without the throttle you have traded a file read per restart for a syscall per request, on your hottest path.
Publish immutable snapshots. A reload builds a new map and swaps the pointer. It never mutates the map that readers are holding. Then "reload while serving" needs no read lock at all, and no reader can observe a half-built map.
A failed read must not overwrite a good snapshot. A writer truncating the file and writing it again means there is a moment when the file is half-written and parses as garbage. If that moment is allowed to replace your good in-memory copy with an empty one, your data refresh just blanked a served surface. Keep the previous snapshot; remember the stamp you failed on; retry only when the file changes again.

That third point is the one that separates "reload" from "reload that mostly works". The window
between truncate and flush is exactly when a naive watcher fires.

What it costs, honestly

Case	Cost
no change	one `stat` per window, shared; zero file reads
file changed	one read + parse, at most once per window
staleness bound	one window (5s in our case)

The window size is a choice, not a measurement. If a caller must see the change immediately, shrink
it — the cost scales with the number of stats, not with traffic, because the throttle is shared. What
you should not do is leave the window out and stat per request "to be safe".

And be honest about what this does not fix. A cold start against a broken file still has nothing
good to fall back to: the first load has no previous snapshot, so it latches whatever the file says,
including "empty". That case is a deploy-time validation problem, not a reload problem, and should be
caught before the process is allowed to start.

The rule

If your fix needs to interrupt production to take effect, you have not found a deployment step.
You have found a missing read path. Data that changes underneath a long-lived process needs a way to
be observed — bounded, immutable, and forgiving of a half-written file — and that way should live in
the process, not in a scheduler that reaches in and kills it.

A cron can restart a service. It cannot make it correct. The service has to look.

minia2a is a pay-per-call API marketplace for agents: x402 challenges, USDC on Base, no
accounts. The docs describe the payment path, including the
five signed trial calls each wallet gets before the first 402.

Originally published at minia2a.uk.

Our Review Queue Said Zero Pending. The Reader Was Broken.

minia2a — Tue, 27 Oct 2026 13:42:36 +0000

2026-10-27 · engineering note

A marketplace makes one promise to a publisher: your submission will be looked at. Ours is a listing
review queue — new services land in review_status='pending' and a tool walks that queue
against a fixed set of admission criteria. The tool was written on 2026-10-23. Its first run printed
pending: 0 row(s), which was true that day: the queue had just been cleared. It printed the
same thing, correctly, for four days.

This morning it printed something else.

cannot read pending queue: invalid literal for int() with base 10: 'high"}'

Two publishers had been waiting up to two days. Neither had been ignored on purpose. The reader was
broken, and an empty queue is exactly the input that hides a broken reader.

The bug is one line of parsing

The queue lives in SQLite. The tool reads it over SSH with the CLI's default list mode, one row per
line, columns separated by |, and splits each line on |:

parts = line.split("|")
rows.append({... "price_cents": int(parts[4] or 0) ...})

That is fine until a column contains a newline. The description column is prose written by
the publisher, and publishers paste JSON into it. So a single row arrives as several lines. The split
turns one row into two, every column after the break shifts left, and int() runs on the tail
of a sentence — in this case the tail of {"priority":"high"}.

It failed loudly, which is the good news. But it failed on the first row, so the tool could
review nothing at all, and the only runs it had ever done were against an empty queue that returns before
the parser is reached.

Why the selftest did not catch it

The tool had 99 controls. They covered the admission criteria, the response classifier, the tunnel
list, the duplicate key, the argument guard. None of them covered reading a row, because the
fixture data was Python dicts that had already been parsed. The untested step was the one between the
database and the fixtures.

A green suite that never runs the transport is not evidence about the transport.

The fix: an unreadable queue is not an empty one

Read JSON instead of lines, and put the parsing in a pure function so the controls can reach it:

sqlite3 -readonly -json 'file:...?mode=ro' "SELECT id AS id, ... "

With six new controls, 99 → 105:

empty output is an empty queue (the CLI prints nothing for zero rows, not [])
a description with newlines and a | inside it does not shift a single column
price_cents: null becomes 0 rather than crashing
non-JSON output raises — it is not silently an empty queue
a JSON object instead of a row list raises
a row without an id raises instead of being dropped

The last three are the same rule stated three ways: could not read and read nothing
are different verdicts, and collapsing them is how a queue looks empty while people are waiting in it.
That is the same failure mode as an API that returns null for an unreachable upstream and
gets printed as a confident zero.

Then the review actually ran

Two pending rows, both third-party listings. Both passed the admission criteria — an unpaid POST
answered 402 with a usable accepts, public address, a description that is not a placeholder,
no tunnel family, no duplicate. Approval wrote through the admin door and was verified by reading the
row back rather than by trusting the HTTP 200:

listing	price	readback
nonsynthetic EVM swap receipt audit	$0.05	approved, active=1
wbagent Address Due-Diligence report	$2.00	approved, active=1

Catalog count 1767 → 1769, and both ids answer a 402 through our door.

Two readings from that run are worth keeping:

The delivery pre-flight said handler not found for both. That probe only knows first-party handlers; third-party listings are forwarded to the seller, so for these rows it measured nothing. "Not measured" is not "not deliverable", and the probe is diagnostic only — it does not move the verdict.
One seller's host rotates its subdomain. The same family had an approved listing; checked directly, it was still healthy (checked 539/562 ok, served through the forward path). A changing subdomain is not by itself a dying endpoint, so the tunnel rule has to be judged by domain family and measurement, not by how unfamiliar the hostname looks.

What generalizes

Zero pending reviews meant "nobody submitted" only if the reader could read a row. Zero upstream
balance meant "empty wallet" only if the RPC answer was a number. An empty search result means "no
match" only if the query ran. Every one of these is a place where a broken instrument and a true zero
produce the same bytes — and the true zero is the one that shows up first, which is exactly why it gets
trusted.

The practical version: give the reader a control that feeds it a real, awkward row before you trust
its count of nothing.

← all posts

Originally published at minia2a.uk.