DEV Community: Session Replay

Your package.json Says What You Asked For. Only the Lockfile Says What You Got.

Vladimir Elchinov — Tue, 13 Oct 2026 12:58:45 +0000

Ninety-seven malware advisories were published to the GitHub Advisory Database yesterday: 94 npm packages and 3 PyPI. I pulled them with type=malware and read the names, and they split into two very different campaigns.

Most were forks of one popular library republished under scopes nobody has heard of. Ten were something else: names shaped like somebody's internal packages rather than like public ones. @tesla-insurance/vinless-quote. @airbnb-extended/typescript-config. app-sca-info-banking. unified-platform. risk-detection.

That second group is dependency confusion, and the usual explanation of it stops one step before the part that decides whether you are exposed.

The explanation everybody repeats

An attacker publishes a package to the public registry using the name of one of your private, internal packages. Your install picks up theirs instead of yours.

True, and it leaves out the mechanism, which is the only part you can act on.

What actually decides it

npm's own documentation is plain about this. A scope can be bound to a registry, in .npmrc:

@myco:registry=https://reg.example.com

and then, in their words, "once a scope is associated with a registry, any npm install for a package with that scope will request packages from that registry instead." They also note that "scopes have a many-to-one relationship with registries: one registry can host multiple scopes, but a scope only ever points to one registry."

Without that line, there is no association to honour, and the request goes to the default registry like any other.

So exposure here is a configuration property, not a property of your dependencies. It is decided by a file most people have not opened this year, and it is the same answer for every package in that scope.

Which is why the reflex fix does not work

Ask a room what stops dependency confusion and somebody will say pin your versions. Exact versions, save-exact, no carets anywhere.

Pinning constrains which version. It says nothing about which registry answered. If the request is going to the public registry and an attacker has published your package name there, 1.2.3 matches their 1.2.3 exactly as happily as it would have matched yours. A pin is a defence against an upgrade you did not want, which is a different attack.

The lockfile is genuinely better, and still not the control you want. npm says it exists so that "subsequent installs are able to generate identical trees, regardless of intermediate dependency updates". Identical to what was resolved before. It protects what is already in it. A dependency added this afternoon resolves fresh, against whatever registry is configured now.

The field that answers the question

There is exactly one place in a normal project that records where a package came from, and it is not package.json. It is the resolved field in the lockfile, which npm documents as "the place where the package was actually resolved from. In the case of packages fetched from the registry, this will be a url to a tarball."

Which makes the audit a one-liner. Count the hosts your tree actually came from:

jq -r '.. | .resolved? // empty' package-lock.json \
  | awk -F/ '{print $3}' | sort | uniq -c | sort -rn

On a healthy private-registry project that prints your internal host and registry.npmjs.org, and nothing else. Anything third is worth ten minutes. And if a scope you believe is internal shows up under the public host, you have found the thing before somebody else did.

The part that generalises past npm

Look at what was true the whole time this was going wrong. The manifest was correct: the package name in it is the one you meant. The version was correct. Code review passed, because the diff showed a dependency you recognised. Every artefact a person would naturally read says the right thing.

The only record of what actually happened lives in a generated file that nobody opens, reviews, or reads in a pull request, and that most teams have at some point added to .gitignore by accident.

That shape is worth recognising, because it is not rare. When somebody tells you their build started failing or behaving strangely after an install, the question is never what was requested. It is what was fetched, at that moment, on that machine. Those are different claims, and only one of them is written down.

The Browser Closed Your Paragraph Early, and Your CSS Stopped Applying

Vladimir Elchinov — Mon, 12 Oct 2026 13:00:43 +0000

Write this, then read back what the browser actually built:

<p>before <figure>FIG</figure> after</p>

I parsed it in Chrome this morning. What comes back is not that:

<p>before </p><figure>FIG</figure> after<p></p>

Four things happened that nobody asked for. The paragraph closed before the figure. The figure became a sibling rather than a child. The word after is now a bare text node hanging directly off <body>, in no paragraph at all. And the </p> you wrote arrived too late to close anything, so it opened and closed a new empty one.

Here is the measurement, which you can run in any console:

const parse = (html) => {
  const doc = new DOMParser().parseFromString('<!doctype html><body>' + html, 'text/html');
  return { html: doc.body.innerHTML, paragraphs: doc.body.querySelectorAll('p').length };
};

parse('<p>before <figure>FIG</figure> after</p>');
// { html: '<p>before </p><figure>FIG</figure> after<p></p>', paragraphs: 2 }
parse('<p>before <span>SPAN</span> after</p>');
// { html: '<p>before <span>SPAN</span> after</p>', paragraphs: 1 }

div and ul behave exactly like figure. span does not, and the difference is the whole mechanism.

This is specified behaviour, not a quirk

The HTML Standard says a p element's end tag can be omitted

if the p element is immediately followed by an address, article, aside, blockquote, details, dialog, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, search, section, table, or ul element

"Can be omitted" is the author-facing half of that sentence, and it reads like a convenience. The parser-facing half is that the tag is omitted whether you wrote it or not. Because the standard requires it, this is not a rendering difference you can test your way around in another browser. I measured Chrome; any conformant parser is obliged to build the same tree.

What it actually costs

The orphaned text is the part that bites. Every rule you wrote for p stops applying to it: line-height, max-width, margin, font-size, the lot. Half your sentence inherits from body and the half above it does not, so the spacing changes partway through what the reader sees as one paragraph. The empty <p> adds a margin on top of that, and it is not in your source to find.

That is a strange defect to receive. It is visible, it is clearly a layout fault, and it is confined to one page and one place on it.

Where it comes from, since nobody types this

Three routes, and the author is not wrong in any of them:

A template or component wrapping a body in <p>, where that body can contain a figure, a table or a code block.
A markdown or CMS pipeline that renders an image, an embed or an attachment as a <figure> and lets it land mid-paragraph. I hit this last week in a publishing pipeline, which refused the file rather than render it, and that refusal is the only reason I looked.
Rich text pasted into a field whose output gets wrapped in <p> on the way out.

The part you cannot see from the source

Here is the uncomfortable bit, and the reason this is worth knowing rather than just fixing. The defect does not exist in your template, your markdown, or your CMS record. All three are exactly what you intended, and re-reading them proves nothing. It exists only in the tree the parser built.

So the report arrives as "the spacing looks wrong on that page", from somebody who cannot tell you which half of which paragraph, and you cannot reproduce it by reading the file that produced it. Opening the page yourself may not help either, because the condition is in the content: it needs the paragraph that happened to contain a figure, which is one article out of two hundred.

The only artefact that shows the fault is the DOM as it was built at the time, on the page the reader had open. That is never what gets sent.

A cheap assertion

Both of these should be zero on a content page, and neither is on a page with this defect:

// Point this at whatever wraps your rendered content, not at body:
// on most pages the prose lives inside <article> or <main>.
const root = document.querySelector('article, main') || document.body;

const orphans = [...root.childNodes]
  .filter(n => n.nodeType === Node.TEXT_NODE && n.textContent.trim());

const empties = [...root.querySelectorAll('p')]
  .filter(p => !p.textContent.trim() && !p.children.length);

console.log({ orphans: orphans.length, empties: empties.length });

Cheap enough to assert in whatever test already renders your templates, which turns a layout report nobody can reproduce into a failing build.

If you take one thing from this: a correct source file and a correct DOM are two different claims. The parser sits between them, and it is allowed to disagree with you.

I Tested the "unload Blocks bfcache" Rule and My Page Was Restored Anyway

Vladimir Elchinov — Fri, 09 Oct 2026 12:59:30 +0000

Microsoft's Edge release notes on 8 October carried an announcement about the unload event: as of Edge 155 the rollout reaches 100% of page loads, and handlers no longer run unless a site opts in through Permissions Policy. The note adds the standard reasoning, that unload "can prevent pages from using the back/forward cache".

Which is the version of this everybody repeats, usually without the "can": register an unload handler and your page is ineligible for bfcache.

I tested it. The page was restored from bfcache anyway.

The test

On a page in Chrome 154, register the handler and a marker, navigate away, navigate back:

window.__log = [];
addEventListener("pageshow", (e) => window.__log.push(`persisted=${e.persisted}`));
addEventListener("unload", () => {});
window.__marker = "1zw4n1";

After going forward to another page and then back:

{ "marker": "1zw4n1", "pageshowLog": ["pageshow persisted=true"] }

persisted=true is the browser telling you directly that this was a back/forward cache restore, and the surviving marker says the same thing a second way: the JavaScript context was never torn down.

So on that browser, on that page, an unload listener did not prevent the restore.

What I am not claiming

One measurement, one browser version, one page, with the handler attached at runtime rather than present in the original source. That is not a new rule, and if you take "unload no longer blocks bfcache" away from this you have swapped one piece of folklore for another.

The eligibility rules differ by engine, by platform, by whether the handler was there at parse time, and now by whether the deprecation rollout has reached that page at all. That last one is new and it is the interesting part: if the handler is never going to fire, there is less reason for it to disqualify anything.

The conclusion is not a rule. It is that this is a question you should stop answering from memory.

Because the browser will just tell you

PerformanceNavigationTiming has a notRestoredReasons property, and it is present in Chrome 154:

const nav = performance.getEntriesByType("navigation")[0];
console.log(nav.notRestoredReasons);

It reads null on a fresh navigation and on a successful restore, and it is populated when the browser tried to restore from bfcache and could not, with the reasons and the frame they belong to. So instead of reasoning about which of your handlers might be disqualifying the page, you ask the page.

Log it once and look at real navigations:

addEventListener("pageshow", (e) => {
  const nav = performance.getEntriesByType("navigation")[0];
  if (!e.persisted && nav?.notRestoredReasons) {
    navigator.sendBeacon("/metrics/bfcache", JSON.stringify(nav.notRestoredReasons));
  }
});

Where it is missing you learn nothing, which is honest, and better than a confident wrong answer.

The part that costs you something

Cache eligibility is the small half. The large half is that the same uncertainty governs whether your exit-time reporting runs at all.

If your analytics or your error reporter batches events and flushes them in an unload handler, then on Edge that code has been running for a shrinking share of page loads since 152 and, from 155, for none of them. No error. No console warning. No failed request. The handler simply is not called.

And the events you lose are a specific set: the last error before somebody left, the queued batch, the "abandoned at this step" signal. The ones about leaving.

Use pagehide and visibilitychange, and sendBeacon rather than fetch, because a beacon is specified to outlive the page. But the migration is not the lesson. The lesson is that you cannot tell from the client whether it worked. A handler that never runs looks exactly like a handler that ran and had nothing to send, and from inside the page both are silence.

So verify it where the evidence survives: count arrivals on the server, grouped by browser major version. If one browser's exit beacons per session fall while its page views do not, you have found it. That number is the only thing in this whole area that cannot be argued with, and it is the one almost nobody plots.

The general shape

A staged deprecation does not announce itself in your logs. It shows up as a slope in a number you are probably not watching, and the thing it takes away is evidence, which is the one category of loss that hides its own size.

Ask the browser what it did. Count what arrived. Do not recite what used to be true.

Your Offline Banner Fires on a Guess, and a VPN Can Flip It

Vladimir Elchinov — Thu, 08 Oct 2026 12:59:50 +0000

Somewhere in most front ends there is a line like this:

if (!navigator.onLine) showOfflineBanner();

MDN's page for that property contains a sentence that should probably be in a larger font:

Therefore, this property is inherently unreliable, and you should not disable features based on the online status, only provide hints when the user may seem offline.

Not "be careful with". Do not disable features based on it. The reason is what it actually measures, which is not reachability.

It fails in both directions, for documented reasons

MDN names the mechanisms, and they are worth reading as two separate bugs rather than one caveat.

It says true when nothing works. In MDN's words, "connection to LAN is considered online, even though the LAN may not have Internet access", and "the computer may be running a virtualization software that has virtual ethernet adapters that are always 'connected'". So a developer with Docker running, or anybody on a hotel wifi that has not been paid for yet, is online as far as the property is concerned.

It says false when everything works. This is the one that will reach your inbox. Again from MDN: "On Windows, the online status is determined by whether it can reach a Microsoft home server, which may be blocked by firewalls or VPNs, even if the computer has Internet access."

Read that again with your user base in mind. The browser decides whether your app is online by whether it can reach Microsoft. On a corporate network, behind a VPN that routes split-tunnel or a firewall that drops unrecognised destinations, that probe fails and the flag goes false while your API is perfectly reachable.

If you disabled the save button on that flag, you disabled it for exactly the users who are on a managed laptop.

The second thing people reach for is also a hint

When onLine disappoints, the next stop is usually navigator.connection. It is worth knowing what that returns before building on it. Read from the machine I am writing this on, a desktop on wifi:

{ "onLine": true, "effectiveType": "4g", "rtt": 50, "downlink": 10 }

effectiveType is "4g" on a wired-speed connection with no radio involved, because the label is a bucket for "fast", not a statement about the network type. The rtt and downlink figures are rounded into coarse steps on purpose, to make them less useful for fingerprinting. They are a hint about conditions, and nothing in them tells you whether your own API answers.

The only honest check is a request you control

There is exactly one way to know whether your app can reach your server, which is to ask your server:

async function reachable(timeoutMs = 3000) {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), timeoutMs);
  const started = performance.now();
  try {
    const res = await fetch("/health", { method: "HEAD", cache: "no-store", signal: ctrl.signal });
    return { ok: res.ok, status: res.status, ms: Math.round(performance.now() - started) };
  } catch (e) {
    return { ok: false, status: e.name, ms: Math.round(performance.now() - started) };
  } finally {
    clearTimeout(timer);
  }
}

cache: "no-store" is not decoration: without it a cached 200 will tell you the network is fine while it is down. The timeout matters because the interesting failure is not refusal, it is silence.

Use navigator.onLine as MDN suggests, to decide whether it is worth asking at all, and never as the answer.

And why this ends up in a ticket you cannot close

Here is the shape of the report. "Your app kept telling me I had no internet. My internet was fine."

That is unfalsifiable, and the reason is that the flag leaves no trace. It is a boolean with no provenance: nothing records which heuristic produced it, what the browser probed, whether it was a virtual adapter or a blocked reachability check. You cannot reproduce it either, because you are not behind their VPN and your machine is not running their endpoint protection.

The fix for the ticket is the same as the fix for the code. If something is going to tell a user they are offline, record the evidence it decided on: the status and timing of a request you control, not the boolean. {"ok": false, "status": "AbortError", "ms": 3000} is a bug report. navigator.onLine === false is an opinion.

Everything above is one instance of a thing worth generalising: when a browser API gives you a single boolean for a condition that has ten causes, the boolean is not evidence about any of them.

Your Console Screenshot Shows Values That Never Coexisted

Vladimir Elchinov — Wed, 07 Oct 2026 12:59:12 +0000

Three lines, from MDN's own documentation for console:

const obj = {};
console.log(obj);
obj.prop = 123;

That logs {}. Expand the object in the console afterwards and you see prop: 123.

MDN states the mechanism plainly: "Information about an object is lazily retrieved. This means that the log message shows the content of an object at the time when it's first viewed, not when it was logged."

Not when it was logged. That is the whole article, and it has a consequence most people have never had to think about.

The common explanation is wrong

The usual account of this is that console.log is asynchronous, and that you are seeing a race. That is not what happens. The call is synchronous and the message is recorded at the moment you make it, in order, with the right timestamp.

What is deferred is reading the object's contents. The console message holds a reference, not a copy, and the contents are serialised when something asks to see them. If nothing ever expands that line, nothing ever reads it. If you expand it four minutes later, you get the object as it is four minutes later, under a line stamped four minutes ago.

Primitives do not behave this way. console.log(count) captures the number. It is objects, arrays, Maps and anything else held by reference where the line and its payload can come from different moments.

Which breaks the single most requested artefact in bug reporting

"Send me the console" is the most common follow-up question in software, and for good reason: a red line in the console is often the whole answer.

Now think about how that screenshot gets made. Something goes wrong. The user, or a colleague, opens developer tools after the fact, finds the interesting line, clicks the arrow to expand the object, and screenshots what appears.

Every expanded object in that image was read at screenshot time. The log line next to it was written earlier. If your code mutates the object it logged, and most code that logs state does, then the screenshot shows a pairing of time and value that never existed.

You then debug against it. You read status: "settled" against a line that fired during pending, and you look for a bug that explains how a settled order got into the pending branch. There is no such bug. There is a viewer that read the object late.

And two reporters can hand you contradictory evidence, both honest

The split that makes this genuinely nasty: whether the value is stale depends on whether somebody clicked the triangle.

A collapsed line often shows a preview rendered at log time. Expanded, it shows the current contents. So one reporter who screenshots without expanding and one who expands first can send you two images of the same console on the same bug, disagreeing about what the object held, and neither of them has done anything wrong or touched anything.

If you have ever had two tickets for the same fault that contradicted each other on a detail and closed one as unreproducible, this is a candidate for why.

The fix in your own logging

If the object is going to be mutated and the moment matters, clone it at the point of logging. MDN's suggestion:

console.log(JSON.parse(JSON.stringify(obj)));

and it notes that structuredClone() is more effective for cloning different types of object, which it is: JSON round-tripping silently drops functions and undefined, turns Date into a string, and throws on anything circular.

console.log("order before dispatch", structuredClone(order));

The cost is real and worth stating. Cloning is work at log time rather than at view time, which is the wrong trade on a hot path, and it loses the things a reference gives you: a live object you can keep expanding, DOM nodes, class instances with their prototypes. So do it where the object is mutable and the timing is the point, and leave the reference where you are logging something you only ever read once.

The rule underneath it

A log line's timestamp tells you when the call happened. It tells you nothing about when its payload was read.

Anything that reads later is reading later, and that includes the viewer in your browser. A collector that serialises at the moment of the call gets a different answer from a viewer that serialises on expand, and the difference is not a bug in either of them. It is the difference between a snapshot and a reference, and only one of the two is evidence about a moment.

Your Bug Report Says Intel Mac on Catalina. The Machine Is Neither.

Vladimir Elchinov — Tue, 06 Oct 2026 13:00:28 +0000

Here is the User-Agent string Chrome sent from the Mac I am writing this on, read out of the browser a few minutes ago:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36

Three of those facts are false. The machine is not Intel, it is ARM. The OS is not 10.15.7, which is Catalina and shipped in 2020; it is 26.6.2. And Chrome is not 154.0.0.0, it is 154.0.8037.93.

None of that is a bug. It is the documented design. Chromium's own User-Agent reduction page says the macOS platform version is frozen at 10_15_7 and the browser version is reduced to 0.0.0, with the reduction fully in place from Chrome 113. The macOS freeze exists because when browsers started reporting Mac OS X 11_*, a long tail of sites broke on it.

So the string is behaving correctly. The problem is what we do with it.

A measured field can be confidently wrong

Most advice about environment fields in bug reports is about getting them measured instead of typed, because a person recalling their OS version is guessing and a script reading it is not. That advice is right and it is not enough.

If your collector reads navigator.userAgent and parses it, your tickets now carry an OS field that is measured, consistent, and wrong on every Mac you will ever receive a report from. It is worse than a typed field in one specific way: nobody audits it. A typed macOS, I think the latest one invites a follow-up question. Intel Mac OS X 10.15.7, sitting in the field a script filled in, reads as fact.

Then somebody tries to reproduce. The ticket says Intel, Catalina. If you are diligent, you go and find an Intel machine, or spin up a VM with an OS from 2020, and you fail to reproduce a rendering bug that only happens on Apple silicon. You write cannot reproduce and close it. The reporter, who is on an ARM Mac on macOS 26, files it again next week.

That is the cost, and it is paid by whoever is least able to argue with the field.

Getting the real values

Everything the string used to carry is still available, through client hints. The catch is the shape of the API.

const d = navigator.userAgentData;

const hints = d?.getHighEntropyValues
  ? await d.getHighEntropyValues([
      "platformVersion",
      "architecture",
      "bitness",
      "uaFullVersion",
    ])
  : null;

On the machine above that returns:

{
  "platform": "macOS",
  "platformVersion": "26.6.2",
  "architecture": "arm",
  "bitness": "64",
  "uaFullVersion": "154.0.8037.93",
  "model": "",
  "mobile": false
}

Which is the truth, and not a value you can get any other way.

Two things about that snippet are load-bearing.

It is a promise. getHighEntropyValues is asynchronous, and a collector that builds its payload synchronously when somebody clicks a button will post before it resolves. The failure mode is not an error: the field is simply absent or empty, on every report, and nobody notices for months because an empty environment field looks like a configuration choice. If your capture runs in a click handler, the await has to be inside it and the submit has to wait.

It is not everywhere. MDN marks navigator.userAgentData as experimental, with "limited availability" because it "does not work in some of the most widely-used browsers". So the optional chaining is not decoration. Where the API is missing you are back to the frozen string, and the honest thing is to record that you could not measure the OS version rather than to parse 10_15_7 and present it as one.

That second branch is the one worth building deliberately. A field that says unknown is a field somebody will ask about. A field that says Catalina sends them to the wrong machine.

The general shape

The useful habit is not "measure, don't ask". It is: know what each field is measuring, and what it is capable of measuring.

The UA string is measuring what the browser has decided to disclose by default, which since 2023 is deliberately less than the truth. Client hints measure the truth, if you ask for it, asynchronously, where the API exists. Those are two different instruments with the same name on the form, and only one of them can answer the question your reproduction attempt is about to depend on.

This one came out of a comment from @phongdesigns on an earlier piece here, who pointed out that measured is not the end of the question and measured by what is. That is the sharper version, and it is the one I would start from now.

Your Template Set the Title. Something Else Decided What Shipped.

Vladimir Elchinov — Mon, 05 Oct 2026 12:58:17 +0000

A page of ours returns 200. The HTML validates. Every test is green. The h1 reads exactly what we wrote. And for several weeks it was shown to about 1,580 people a month in search results and clicked once.

One click. At an average position of 8.7, where the usual click-through is somewhere between one and two per cent, so the expected number was twenty or thirty.

Nothing was broken in any sense a test or a log would recognise. What was broken was the <title> element, and it was broken in a way that nothing inside the application could see.

One variable, two outputs

The controller builds a single string and hands it to both places that need it: the page title and the Open Graph title. One assignment, two consumers, same value.

What came out the other end was not the same value twice.

h1       (68): TypeError: Failed to Fetch - What It Means and How to Find the Cause
og:title (68): TypeError: Failed to Fetch - What It Means and How to Find the Cause
<title>  (58): TypeError: Failed to Fetch - What It Means and How to Find

A view helper fits the title element to a character budget, cutting on a word boundary. That is a reasonable thing for a site to do and it was added deliberately. The point is not that the truncation is wrong. The point is that nothing at the call site says it happens, the other two consumers of the same string are untouched, and the result is a sentence that stops before its own subject.

That is the page with the 1,580 impressions. The half it loses, "the Cause", is the half somebody searching for the meaning of an error is actually looking for. Four of our highest-traffic pages were shipping a title that ended mid-phrase like this; another stops at "and the Keyboard Key", dropping the thing the article is about.

Why no test caught it

Because every test asserted on the value we set, not the bytes that left.

The model holds the full string. The controller holds the full string. The template is handed the full string. You can write a perfectly good test at any of those layers, watch it pass, and learn nothing, because the transformation happens below the lowest layer anybody thought to assert on.

This is a general shape and it is worth naming: for any output whose consumer is outside your process, the thing to assert on is the rendered bytes. Search results, email clients, social cards, RSS, webhook payloads, PDF exports. Every one of those goes through a layer that can reformat, truncate, escape or re-encode what you set, and every one of those consumers is somewhere your test suite is not.

The test that would have caught it is boring:

test "the title element ships the whole headline" do
  get article_path(@article)
  title = Nokogiri::HTML(response.body).at_css("title").text
  assert_equal @article.title, title
end

It asserts on response.body, which is the only artefact that is actually true. Everything above it is an intention.

The expensive property

What makes this class of fault costly is not severity. It is that it produces no event.

There is no exception, no 4xx, no stack trace, no log line, no alert. The page is correct by every check that runs inside the system that produced it. Monitoring is green because monitoring measures whether the page was served, and it was.

The only evidence exists outside your application, in a number that somebody has to go and look at, in a tool they open occasionally, weeks after the change that caused it. We found ours because a weekly job finally ran after being unavailable for nineteen days, and the number was too strange to ignore.

Until then, every signal we had said the page was fine. Every signal was telling the truth about the thing it measured.

The shape worth taking away

A failure that your system cannot observe is not a smaller problem than one that throws. It is a longer one, because the clock starts when somebody outside notices and decides to tell you, and most of them do not.

That is true of a truncated title, which at least leaves a number behind. It is far more true of the things that leave nothing: a customer whose page half-loaded and who closed the tab, a user who hit an error and shrugged, a visitor who saw a broken image and assumed the site was like that.

Those are the same category. The system behaves correctly from the inside, the only witness is outside it, and whether you ever find out is entirely up to somebody who owes you nothing.

A Hang Is Not an Error, and Every Timeout You Add Turns It Into the Wrong One

Vladimir Elchinov — Fri, 02 Oct 2026 13:00:23 +0000

A command returns nothing. No message, no exit code, no log line, no stack. You wait, then you press ctrl-C, and the only thing you have afterwards is your own memory that it took a while.

This is a different category from a failure, and the difference is not severity. An error hands you a string, a code, a file and a line, and usually a timestamp. A hang hands you nothing at all, and everything built on top of it inherits the nothing: your shell waits, your editor waits, your CI job waits until somebody's limit kills it, and whatever it prints then is about the limit rather than the cause.

The system's own word for it is "slow"

man 2 read on any Unix is unusually blunt about where this comes from:

[EINTR] A read from a slow device was interrupted before any data arrived by the delivery of a signal.

"Slow device" is the whole category in two words. A local SSD is not a slow device. A network filesystem is. So is a FUSE mount, a stalled VPN route, and any cloud file provider that has to go and fetch the bytes before it can give them to you. Every one of those can turn an ordinary open() or read() into a call with no upper bound on how long it takes, and man 2 open says the same thing about opening the file in the first place.

Nothing in your program is wrong. It asked for a file. The answer has not come back.

The error you eventually see names the wrong layer

Here is the part that costs the afternoon. When a stalled read does surface an error, the message describes what the process was doing, not what was wrong.

A runtime that cannot finish loading a script reports that it could not load that script, and names it. So you go and look at the script. It is present. It is readable. You read it yourself in another window and it comes back instantly. You check permissions, you check the interpreter, you check the path, and all of it is fine, because none of it was ever the problem. Three layers down, one file the process touched before it got to yours lives on something that was not answering.

The message is accurate and it points at the wrong thing, which is worse than being wrong, because you can spend hours confirming that an innocent file is innocent.

And every timeout relabels it again

The obvious defence makes the diagnosis harder.

Wrap the call in timeout 30 and you get exit 124, which reads as "this tool is slow". Put that in CI and the job fails with something generic, and the team writes down "flaky". Add a retry and it passes sometimes, which upgrades "flaky" to "known flaky" and buys the real cause another month of life. Each layer swaps the symptom for a label about itself.

What to do instead of debugging the thing that hung

Do not investigate the command. Investigate the syscall it is sitting in.

# Is it blocked, or just busy? U means uninterruptible wait.
ps -o pid,stat,etime,command -p "$PID"

# What has it got open? The culprit is usually the last entry.
lsof -p "$PID" | tail -20

# macOS: a stack for the blocked thread, which names the syscall.
sample "$PID" 3 -file /tmp/hang.txt && grep -m5 -i 'read\|open\|stat' /tmp/hang.txt

# Linux: the same answer, cheaper.
cat /proc/"$PID"/stack; cat /proc/"$PID"/wchan

man ps defines the one that matters: U marks "a process in uninterruptible wait". A process in that state is not slow, it is waiting on something that has not answered, and no amount of reading its source will tell you what.

Then the control experiment, which is the step people skip: run the same operation with one input removed. Point the tool at a different config file, a different working directory, a different mount. If it returns instantly, the input you removed is the slow device, and you have the answer in one try instead of twenty.

Why this one is worth writing down

Because a hang destroys its own evidence. Kill the process and there is no stack, no log line, no exit code, no timestamp: nothing to attach to a ticket and nothing for anybody else to read later. The next person gets "it froze sometimes" and starts from zero.

That is also why "it hung" and "it was slow" are the least actionable things a user can tell you. They are reports about an event that left no artefact, and you cannot go back and collect one, because the only moment the state existed was while somebody was staring at a spinner and deciding whether to wait.

Whatever you want to know about a stall, you have to take it while the stall is still happening.

Your Status Page Is Written in the Present Tense. Bug Reports Are Not.

Vladimir Elchinov — Thu, 01 Oct 2026 12:59:39 +0000

For eight days in late September the network between Tokyo and Singapore was congested because subsea cables had been cut. Cloudflare's status page carried it from 23 September and closed it on the 29th. The cause, in their own words: "multiple subsea cable outages have caused congestion between Tokyo and Singapore datacenters", dating back to 21 September at 02:20 UTC.

No deploy caused it. It threw no errors. And it was more than enough to make a site feel slow across a large part of the world.

What that produces on your side is the worst report you can receive: "the site was slow yesterday". No error, no stack trace, no status code to search for. One region, some users, intermittently. Nothing in your own metrics either, because your monitoring almost certainly runs somewhere the cables were fine.

The asymmetry nobody designs around

A status page is written in the present tense. The front page answers exactly one question: is this broken right now.

A bug report is written in the past tense. It asks a different one: was this broken then.

So by the time somebody mentions the site was slow on Tuesday, the incident has closed and the dashboard says all systems operational. That is true, and useless, and it quietly reads as confirmation that the user imagined it. You close the ticket as not reproducible, and you are both slightly wrong.

The history is an API, and you already depend on several of them

The useful part is that the incident archive is machine readable, on a path that is the same almost everywhere, because most of these pages are the same hosted product rather than something each company built.

I checked five this morning. Every one answered with JSON on /api/v2/incidents.json: www.cloudflarestatus.com, www.githubstatus.com, status.openai.com, www.redditstatus.com and status.datadoghq.com.

Each incident record carries name, impact, status, started_at, resolved_at, the affected components, and the full incident_updates history with a timestamp on every update. Which means "was anything on fire around 14:30 yesterday" stops being a question you ask in Slack and becomes one you answer:

require "json"
require "net/http"
require "time"

def incidents_around(host, at, window: 3600)
  body = Net::HTTP.get(URI("https://#{host}/api/v2/incidents.json"))

  JSON.parse(body)["incidents"].select do |incident|
    times = [incident["started_at"], incident["resolved_at"], incident["created_at"]]
            .compact.map { |t| Time.parse(t) }
    next false if times.empty?

    times.min - window <= at && at <= times.max + window
  end
end

incidents_around("www.cloudflarestatus.com", Time.parse("2026-09-25T09:00:00Z"))
  .each { |i| puts "#{i['name']} (#{i['impact']})" }

One thing that will bite you

Do not assume started_at comes before resolved_at.

Incidents get filed retroactively, when somebody notices afterwards that something was broken and writes it up. The record then carries the time it was written as its start. On GitHub's status page as I write there is an incident titled "[Retroactive] Actions workflow run failures after deployment gate approvals" whose started_at is 11:34 UTC today and whose resolved_at is 02:00 UTC the same day, nine and a half hours earlier.

A natural-looking started_at <= t && t <= resolved_at filter silently excludes exactly the incidents somebody cared enough about to go back and document. Take the minimum and maximum of whatever timestamps the record carries instead, which is what the snippet above does.

The precondition is the whole problem

All of this runs on two inputs: roughly when, and roughly where.

Neither of them comes out of a free-text box. "It was slow yesterday" has neither, and the conversation to get them is the one everybody has had. Which page? I don't remember. About when? Afternoon? A week later the cables are repaired, the report is closed as not reproducible, and the only lesson anybody took is that reporting things here is a waste of time.

So the cheap half of this is a script you write once and keep. The expensive half is arriving at a report that carries a timestamp and a location at all, which is a capture problem rather than an investigation one.

Write the script anyway. It is twenty lines and it will settle an argument every few months. It just cannot do anything with a report that has nothing to join on.

The Error Your User Read Was Not in English, and You Have Been Searching for the Wrong String

Vladimir Elchinov — Wed, 30 Sep 2026 12:58:28 +0000

A support ticket arrives with a screenshot of a browser error page. You read the message, paste a distinctive phrase from it into your codebase search, and get nothing. You search the web for it and get nothing useful either.

Then you look again and notice the page is in German.

This is a small thing that wastes a disproportionate amount of time, and it has a fix so cheap it is almost embarrassing.

Browsers localise the prose and keep the identifier

Chromium's network errors have two parts that behave completely differently.

There is a stable constant, like ERR_NAME_NOT_RESOLVED or ERR_CONNECTION_REFUSED, defined in net_error_list.h with a fixed numeric value and a one-line English description for developers. That identifier does not change between locales, browser versions, or installs.

And there is the text the user actually reads, which is translated into whatever language their browser is running in.

So the same failure that tells you "This site can't be reached" tells somebody else "Diese Seite ist nicht erreichbar" or "No se puede acceder a este sitio web". One underlying condition, one stable code, and dozens of surface strings.

Your instinct when a report arrives is to work from the sentence, because the sentence is the part that looks like information. It is the part that does not survive translation.

Which means the question you are asking is the wrong one

"What did the error say?" is the natural thing to ask and it is subtly the worst version of the question, because it requests exactly the part that is locale-dependent.

"Is there a code, usually in smaller text underneath?" requests the part that is not.

The second question also happens to be easier for a non-technical person to answer, because they are not being asked to transcribe a paragraph or judge what is relevant. They are being asked to find a short string that looks like shouting.

And the answer is searchable. ERR_CERT_DATE_INVALID returns the same results whoever typed it, from wherever. The German sentence does not.

This applies to your own error messages too

Here is the part that costs something, and it is about code you control rather than code you do not.

If your application shows localised error text and nothing else, you have built the same trap. Your Spanish-speaking user reports "Se produjo un error inesperado", you search your source for it, and depending on how your translations are stored you may not find the key, the call site, or the condition that produced it.

The fix is to emit a stable identifier alongside the human text, visible to the user and constant across locales. Something like a short code in the corner of the error state, or in a detail line under it:

Something went wrong. Please try again.
Reference: PAY-4021

PAY-4021 is not for the user. It is for you, and it survives the round trip through a screenshot, a translation, a paraphrase and a support agent's summary, all of which destroy the sentence above it.

The rule of thumb: anything in your error UI that a translator can change is something a bug report cannot reliably carry. If the only distinguishing content in a failure state is prose, you have made every report of it ambiguous by construction.

The wider shape

Localisation is one instance of a general problem with bug reports, which is that the reporter can only send you what the interface showed them, and interfaces are designed for reading rather than for reporting.

The user did not choose to send you an untranslatable sentence instead of a code. They sent you what was on screen. If the screen carried a stable reference, they would have sent that, because it is shorter and more obviously official-looking.

So the next time a report is useless, it is worth asking whether the person failed to describe the problem or whether the screen failed to give them anything describable. Those have different fixes, and only one of them involves the reporter.

Chromium's list of these error constants, with the English description of each, is net_error_list.h. It is worth a bookmark for the next screenshot you cannot read.

A Sanitizer Is Two Parsers Agreeing, and Yours Only Controls One of Them

Vladimir Elchinov — Mon, 28 Sep 2026 12:57:51 +0000

Last week a critical XSS landed in SunEditor, a rich-text editor a lot of applications embed. CVE-2026-59167, CVSS 10, fixed in 2.47.11. The advisory's own one-line summary is the interesting part: sanitizer bypass.

Not "SunEditor had no sanitizer". It had one. The sanitizer ran, did its job as written, and the output still executed JavaScript.

That distinction is worth more than the CVE, because the shape of it is not specific to SunEditor and will outlive this patch.

The assumption that breaks

The mental model most of us carry is that sanitizing is filtering: you take a string of user HTML, remove the dangerous parts, and what remains is safe.

That model quietly assumes there is one agreed answer to the question "what is in this string". There is not. Sanitizing is two parsers agreeing with each other, and you only control one of them.

Your sanitizer parses the input and decides what the elements and attributes are. Later, a browser parses the sanitized output and decides what the elements and attributes are. If those two ever disagree about the same bytes, the browser wins, because the browser is the one that renders it.

Every sanitizer bypass in history is a place where they disagree.

What disagreed this time

The SunEditor advisory names it precisely: the sanitization logic "does not fully remove executable event-handler attributes from certain custom/namespaced tags", and it points at namespaced elements, written like <a:b>, as the construct involved.

You can see the shape of the mistake without the payload. A filter that works from a list of known elements has to decide what to do with an element it does not recognise. <a:b> is not in anyone's allowlist. It is not a real HTML element. A reasonable-looking implementation treats it as unknown, declines to apply the attribute rules it has for real elements, and leaves it alone.

The browser is less fussy. It parses that into an element in the DOM like any other, and an onclick attribute sitting on it is an event handler like any other. The sanitizer saw something it did not recognise; the browser saw something it was perfectly happy to run.

Notice that the sanitizer was not bypassed by a cleverer string. It was bypassed by a construct that fell outside the set of things it had opinions about.

The rule that generalises

Read the advisory's own remediation list and every item is really one instruction:

Normalize DOM elements before sanitization
Explicitly reject or unwrap unknown/custom/namespaced tags
Strip all event-handler attributes from all elements, including unknown/custom elements
Re-validate sanitized output after browser DOM parsing

The instruction is: stop sanitizing the string and start sanitizing the tree. Parse the input with the same engine that will eventually render it, walk the resulting nodes, and decide per node. Then your parser and the browser's parser cannot disagree, because there is only one of them.

And the second half, which is the part people skip: an allowlist has to be a decision about everything, not a decision about the things you listed. "Remove onclick from elements I know" leaves a hole shaped exactly like the elements you do not. "Remove every attribute beginning with on, from every node, whatever it is" does not.

Why this class reaches you badly

Stored XSS has an awkward property: the person who sees it is never the person who can fix it, and usually not even the person who caused it.

An author saves content. A reader loads the page days later and the payload fires in their browser. The developer is the third party in that transaction and observes none of it.

Your server logs are no help, because nothing went wrong on the server. The save returned 200. The page render returned 200. Both are accurate. The entire event happened after the bytes left your machine, in a browser you have no access to, belonging to somebody who has no vocabulary for what they just saw.

So it arrives as "a weird box appeared", or "the page flashed red", or most often as nothing at all, because the reader assumed their own machine was playing up and closed the tab.

That is the uncomfortable takeaway. For a whole class of serious bug, your instrumentation is structurally in the wrong place, and the only witness is someone with no idea what they witnessed and no way to hand you the evidence.

Upgrade SunEditor if you embed it. But the more durable action is to go and look at whatever sanitizes user HTML in your own stack, and find out whether it is reasoning about a string or about a tree.

Your Own Browser Is the Worst Instrument You Own for Testing Your Own Site

Vladimir Elchinov — Fri, 25 Sep 2026 12:57:59 +0000

There is a category of bug that is invisible to the person best placed to fix it, and the reason is structural rather than careless.

The clearest example is the login redirect loop. Your app finds no valid session and redirects to /login. The login page believes it is signed in and redirects back. Round and round, until the browser gives up.

It reproduces for every new visitor. It never reproduces for you, because your session cookie was set weeks ago and is working fine.

You cannot see it, and no amount of care makes you able to. You are in a state the affected person is not in, and you cannot leave it by looking harder.

The reflex, and what it actually covers

The reflex is a private window, and it is a good reflex. It clears cookies, storage and cache, which is genuinely most of the client-side state that makes you unrepresentative.

Here is what it does not touch.

Your account. If the bug depends on a user with old data, an unusual permission set, or a record created before a migration, a private window gives you a signed-out browser and the same database. Sign in again and you are back in your own privileged, well-seeded, three-years-old account.

Your feature flags and experiment buckets. If assignment is by user id rather than by cookie, a private window changes nothing. You are in the variant you were always in. If it is by cookie, you get a random new one, which is not the same as getting the one the reporter had.

Your network position. Same ISP, same resolver, same country, same corporate proxy, same VPN. A regional CDN problem, a DNS record that has not propagated everywhere, or a firewall that only affects one network are all untouched by which window you opened.

Your CDN edge. Your nearest edge node has been warmed by your own traffic for months. A visitor hitting a cold edge somewhere else gets a different first-byte time and, if something is misconfigured, sometimes a different response entirely.

Your device. Same OS, same browser build, same fonts, same locale, same timezone, same screen, same accessibility settings. Every layout bug that only happens at a particular width, and every date bug that only happens across a timezone boundary, is still invisible.

So a private window resets the client, and a large share of what makes your experience unrepresentative was never in the client.

Worth knowing what you are carrying

If you want to see how much local state you are actually holding on a site, this is quick, and the answer is usually more than people expect:

// Run in the console on your own site, in a normal window.
console.log('cookies:', document.cookie.split('; ').filter(Boolean).length)
console.log('localStorage keys:', Object.keys(localStorage))
console.log('sessionStorage keys:', Object.keys(sessionStorage))

navigator.serviceWorker?.getRegistrations()
  .then(rs => console.log('service workers:', rs.map(r => r.scope)))

caches?.keys().then(ks => console.log('cache storage:', ks))

A service worker is the one that catches people out. It can serve a cached shell to you indefinitely while every new visitor gets the current one, which means you and they are running different versions of the front end with no version number anywhere to say so.

What this means for a bug report

The practical consequence is not "test more carefully". It is that for a whole class of bugs, the reporter is holding evidence you cannot regenerate.

Not their opinion of what went wrong. The state: which build they had, what their cookies said, what the network actually returned, what was in the console at the moment it failed. Once they close the tab, most of it is gone, and the gap between "it works for me" and "it does not work for me" becomes an argument neither side can settle.

Which is why "can you try again and tell me if it still happens" is such an expensive question. It asks the one person with the evidence to destroy it and produce a fresh copy, from a state that may not reproduce.

The cheaper question is the one that captures what they had while they still have it. And the cheapest habit, when a report arrives that you cannot reproduce, is to stop treating your own failure to reproduce as evidence. It mostly tells you that you are a different user on a different network on a different machine, which you already knew.