This site publishes twenty-five browser tools — ClojureScript single-page apps compiled by shadow-cljs and served inside org-published pages. Two of them broke in production this month. Both presented identically: a blank panel where the tool should be.

Both were JS exceptions thrown during mount. primality-test threw a.replace is not a function; counting-change called Math.LN2 as though it were a function. In each case the browser said exactly what was wrong, in the console, immediately.

Nobody was reading the console, and there is a structural reason why.

A published page here loads the tool's bundle and the site's advertising and analytics bundle. That second one logs its own errors, routinely, as a matter of course.

So on a published page the question "were there JavaScript errors?" has no useful answer. There are always errors. A gate asserting zero console errors would fail on every page forever, which means it would be turned off within a day, which means it would never have caught either defect.

This is the whole argument of the note, and it is worth stating as a general claim rather than a local one:

An error channel shared with code you do not control is not a signal. It becomes one only when everything else in the page is removed.

A harness that serves each tool with its own CSS and nothing else — no site chrome, no org-publish, no analytics. Twenty-five pages on one static port.

The mechanical parts were unremarkable and are not the finding. Ten tools had no harness page at all, so they could not be opened in isolation; ten more rendered unstyled because their page omitted the stylesheet. Both were generated from the build config so the ports cannot drift from it.

What the isolation bought is the finding: in that harness, a console error is attributable. Nothing else is running. The channel became an oracle, in the sense the parent note uses — a thing that can tell you that you are wrong without being told what right looks like (The Oracle Is the Deliverable, which argues hermeticity is a condition rather than a practice; this is what the condition buys in a browser).

The same two pages, the same afternoon:

All three are correct. They disagree because they listen to different things, and the differences are worth naming because each one is a trap.

The beacon was added to make debugging faster. It made the test suite lie.

Under four parallel Playwright workers, the beacon's sendBeacon POSTs outran the small development server. The browser logged Failed to load resource: net::ERR_CONNECTION_RESET, and the suite's own zero-console-errors assertion reported that as a defect in primality-test — a tool that was, by then, fine.

So the logger added to find defects manufactured one, in the first tool it touched, and the failure was indistinguishable in shape from a real finding.

The fix is to fulfil the beacon endpoint in-process during tests: the page's beacon code runs exactly as it does for a person, and nothing crosses the network. The rule it suggests is stronger than the fix:

Anything instrumenting a test harness must be inert under automation, not merely tolerated by it.

With that noise removed the suite reported two broken tools rather than one, and both fail the same way — picture-language and digital-circuits each emit <line> with empty coordinates. One bug class in two places is a better lead than either failure alone, and it was invisible while the false positive was in the way.

Very little, and the parts that are not are worth naming precisely.

• Whether Bombadil's noConsoleErrors can fire on the known-broken page, or whether the random walk simply never reaches the drawing state. Until that is settled the property is uncalibrated.
• The shared <line> defect in two tools.
• Whether shadow-cljs :browser-test surfaces uncaught exceptions as failures. The Users Guide is silent and it was not tested.