DEV Community: Brian Bauernschmitt

I Thought I Had Three Weeks of Data. One GROUP BY Said Ten Minutes.

Brian Bauernschmitt — Sun, 30 Aug 2026 04:30:24 +0000

---
title: "I Thought I Had Three Weeks of Data. One GROUP BY Said Ten Minutes."
published: true
description: "The process was "running," Docker said "healthy." One GROUP BY told the truth: two five-minute test runs. Silent pipeline failure and the checks that catch it."
tags: postgresql, docker, debugging, devops
canonical_url: https://brokeinprod.dev/debugging/silent-pipeline-failure-ten-minutes-of-data
---

The collection pipeline had been "running since August 5th." Three weeks of one-minute market data, accumulating quietly on my laptop. Then I ran one sanity query before a migration — and watched three weeks shrink to ten minutes.

Start here: A pipeline that ran is not a pipeline that's running.

My setup had no supervisor, it lived in a terminal session, and it wrote to a database inside Docker Desktop on a laptop. Yes, that is three layers of session software, each of which dies silently when you close a lid. The fix is three processes, in order of cheapness: (1) query the data, not the process — max(time) is a one-line monitoring system; (2) supervise anything that must survive your absence (launchd/systemd, not a terminal tab); (3) restore-test your backups before you need them.

The setup

A solo-built market data platform: a Rust binary subscribes to an FX broker's tick stream, aggregates 43 instruments into one-minute bars with microstructure stats (spreads, tradeable counts, mid-price variance), and hands them to a Python consumer that bulk-inserts into Postgres. The database runs in Docker Desktop on my laptop — an explicitly interim home while the permanent hardware was commissioned.

Historical prices you can backfill anytime. Intra-minute microstructure exists only if you were listening when it happened — every day the stream is down is permanently unrecoverable. So the day the pipeline first wrote bars, I noted it as an epoch event: the clock started August 5th.

Then I got busy on other parts of the build. The pipeline was "running."

The symptom

Three weeks later, preparing to migrate the database to its permanent machine, I opened Docker to check on things and got this:

CONTAINER ID   IMAGE                STATUS
a1b2c3d4e5f6   postgres:16-alpine   Up 18 seconds (healthy)

Created 3 months ago. Up 18 seconds — because Docker Desktop had just started, because I had just started it, because it hadn't been running before I looked. Meanwhile ps aux | grep stream_bars returned nothing.

The collector wasn't running either.

At this point I still believed the optimistic version: the pipeline ran for a good while, then "Docker kept crashing" took it down somewhere along the way. Some data lost, but most safe. The logs even offered a villain — a wall of FATAL: database "db_name" does not exist errors repeating every five seconds, loud and red and completely irrelevant (a healthcheck probing a database name that never existed — config drift, harmless to data). The loud error was innocent. The real problem hadn't logged anything, because the real problem was silence. The cause is rarely standing where the symptom is — the same shape as the prose leak, where the broken component was innocent and the context was the culprit.

The diagnosis

The migration plan started with a row count:

SELECT count(*), min(time), max(time) FROM ohlcv_1min;
-- 252 bars · 2026-08-05 11:55 UTC → 2026-08-06 03:34 UTC

252 bars. Across 43 instruments. First red flag: that's ~6 bars per instrument over what the timestamps framed as 15½ hours — EUR/USD alone should produce hundreds. Second red flag: the window ended August 6th, not "sometime recently." Three weeks of assumed history was already down to fifteen hours. Then the query that ended the mystery:

SELECT date_trunc('hour', time), count(*) FROM ohlcv_1min GROUP BY 1;
--  2026-08-05 11:00 |  88
--  2026-08-05 12:00 |   1
--  2026-08-06 03:00 | 163

And with SELECT DISTINCT time — ten distinct minutes. Total. Aug 5, 11:55–12:00. Aug 6, 03:30–03:34. Ten minute-bars × ~43 instruments = 252 rows. The arithmetic closed perfectly, and the story it told was not "pipeline crashed after fifteen hours." It was: the pipeline ran exactly twice, for five minutes each, while I was watching it. Two test runs — I started it in a terminal, watched the bars land, felt great, and moved on. The process died when the terminal closed or the laptop slept, both times. There was never a third run.

Nothing crashed. Nothing failed. Nothing was ever deployed — and the difference between "I ran it and it worked" and "it is running" is the entire discipline of supervision, of which I had built zero.

The fix — three tiers, in order of cheapness

Tier 1 — monitor the data, not the process. Every check I could have pointed at the process (is the PID alive? is the container up?) answers the wrong question. The question is did data arrive? — and the table itself answers it in one line:

SELECT max(time) FROM ohlcv_1min;  -- if this isn't recent, nothing else matters

A bars-per-hour completeness query (the GROUP BY above) run on a
schedule, with an alert when the current hour is short, would have caught this on day one instead of day twenty-four. It costs nothing. It's the first monitoring primitive the platform now has — born as an autopsy tool.

Tier 2 — supervise anything that must outlive your attention. Terminal sessions, Docker Desktop, anything that starts at login: session software. It dies with the session, silently, and a laptop is a machine designed to end sessions — lids close, updates reboot, batteries drain.

The fix is boring and decades old: a real supervisor (launchd on macOS, systemd on Linux) with restart-on-failure, running on hardware whose job is to remain powered. "It's temporary" is not an exemption — my interim setup outlived its first failure by three weeks because nothing was watching.

Tier 3 — restore-test the backup, then trust it. Before touching anything, pg_dump the survivors and actually restore the dump somewhere else, counting rows on the far side. A backup that has never been restored is a hope, not a backup. Mine restored clean — 252 rows, exactly as sad as the original.

The rule of thumb

If a human started it, then a human's logout will kill it. If you haven't queried the data since you deployed it, you don't know it's running — you remember it running, which is a different thing. And when something breaks: the loudest error in the log is usually a bystander; interrogate the silence instead.

I'll confess the part that stings: the epoch note. I wrote down the day the clock started — August 5th, 11:46 UTC — like a foundational ceremony, because for this dataset, history only exists if you're documenting it. Then I spent three weeks not listening to the listener.

The data I was so careful to timestamp stopped nine minutes after the ceremony, and I found out from a GROUP BY twenty-four days later. The clock I actually started was the one measuring how long a solo builder can believe in a pipeline nobody is watching. Answer: about three weeks. LOL!

The pipeline worked end-to-end, twice, flawlessly. That was the trap — "it works" and "it's running" are different claims, and only one of them shows up in a demo. The database knew the truth the whole time. All I had to do was ask it.

FAQ

Wasn't the real bug the Docker crashes?
No — that's the misdirection for which this post exists. Docker Desktop stopping when the laptop reboots isn't a crash; it's the documented lifecycle of session software. The bug was architectural: no component anywhere owned the job of keeping the pipeline alive.

Why not just check the logs?
The consumer's logs died with its terminal. The database logs were full of a loud, harmless red herring (a healthcheck probing a wrong database name). Logs tell you what happened; only the data tells you what didn't. max(time) interrogates the absence.

What actually catches this in production?
Freshness checks (max(time) vs. now) and volume checks (rows per window vs. expectation), scheduled, with alerts. Process supervision keeps things running; data-level checks tell you when "running" stopped meaning "working." You want both, and if you can only have one, take the data check.

Did you lose anything irreplaceable?
Three weeks of intra-minute microstructure that can never be backfilled — the one data class where absence is permanent. The consolation: it happened during an interim window before the data carried production load, which made it the cheapest possible version of this tuition.

Tailwind Typography's prose Is Leaking Into Your Components — and the Three-Tier Fix

Brian Bauernschmitt — Sat, 29 Aug 2026 14:52:35 +0000

My CTA button had underlined links and the wrong text color, and no matter which utility class I stacked on it the issues didn't correct. The culprit wasn't the button. It was the prose class, forty lines up in the code.

Start here: The prose class from @tailwindcss/typography styles every matching element beneath it — headings, paragraphs, and yes, the <a> inside your custom button component rendered mid-article. That's its job: it's built for HTML that you don't control and applied to a tree you partially do. I have three fixes, in order of preference: (1) design your in-article components to match prose's expectations so there's no fight; (2) re-tune prose itself with element modifiers (prose-a:…) on the container; (3) wrap genuinely custom islands in not-prose — the sledgehammer, with caveats.

The setup

An article layout on a content site: MDX renders inside a wrapper carrying prose from @tailwindcss/typography — on this build, exactly this:

<div className="prose prose-stone max-w-none font-serif">
  <MDXRemote source={article.content} … />
</div>

Which is the right call — it's the fastest way to make Markdown-sourced body text beautiful. However, articles aren't only Markdown. This build renders custom components inside the article body: styled CTA links, product cards, callouts.

The components came out wrong: link colors overridden toward prose's palette, underlines appearing on things designed not to have them, spacing around the components inheriting article rhythm.

The symptom

The confusing part is where you look. The component's own classes are correct — you can read them right there in the JSX. However, rendered inside the article, the element picks up styling that the component never asked for. The plugin's own issue tracker has this exact report: a button rendered inside prose content, underlined, resisting utility overrides.

The trap: you debug the component, but the cause is the context — the same debugging shape as the fs is not defined bug: correct code, wrong place. prose works by descendant selectors — .prose generates rules targeting the elements beneath it (a, h2, ul, img, …).

Any matching tag in the subtree is in scope, and your component's markup is, structurally, just more tags in that subtree. prose cannot tell your hand-built CTA from a Markdown link. This is NOT a bug, but rather it's the feature, meeting markup it wasn't warned about.

The diagnosis

The plugin is designed for "HTML that you don't control." The moment you embed components that you do control inside it, two styling authorities claim the same elements. Now, which one wins any given property is a cascade question (the modern plugin deliberately keeps specificity low via :where()), but the practical result is consistent: properties your component doesn't explicitly set get prose's values, and the fight over the ones it does set is decided by CSS order — a place you don't want load-bearing logic.

So the fix isn't "win the specificity war." It is deciding, deliberately, which styling authority owns what.

The fix — three tiers, in order

Tier 1 — match prose's expectations (the fix that isn't a fight).

For components that are content — inline CTAs, emphasized links — the cleanest move is to design them to cooperate: let them inherit prose's link color and underline, but differentiate with weight or an accent border instead.

This build runs Tier 1 on both of its content-like components: (1) the inline affiliate link is deliberately bold+underlined in the article's accent, and (2) the CTA button settled on light background, dark text (text-stone-900), and an accent border — colors with which prose has no quarrel.

The idea is to swim with the current, not against it. Zero CSS conflict, and the components read as native to the article — which is what readers trust anyway.

Tier 2 — re-tune prose itself with element modifiers.

When you want prose's rules changed everywhere — say, links in your brand color, no underline until hover — set it on the container, once:

<article class="prose prose-a:text-emerald-700 prose-a:no-underline hover:prose-a:underline">

This is the supported customization channel: you're not fighting with the plugin, but rather you're configuring it. Good for house-style adjustments; however, it's the wrong tool for "this one component is special."

Tier 3 — not-prose for genuine islands.

For embedded UI that is not content — a product comparison card, an interactive demo, a form — sandbox it:

<div class="not-prose">
  <ProductCard … />
</div>

Prose styles stop at the boundary, which means that the island styles itself from zero. Two documented caveats: (1) you can't nest a new prose region inside a not-prose block, and (2) the island now gets none of the typographic defaults — every margin and font size inside is your job again. It's the right tool for cards and widgets; it's overkill (and extra work) for a styled link.

The rule of thumb

Content-like → Tier 1 (cooperate). House-wide preference → Tier 2 (configure). True UI island → Tier 3 (sandbox). If you find yourself stacking !important-flavored utilities on one element inside an article, you've skipped a tier.

I'll confess how I know the fourth option is worse: I took it. Late one evening, I was tired of the cascade fight, so I ripped the typography plugin > out of the build entirely. The buttons looked right — but every heading, paragraph, and list in the article went back to unstyled browser defaults, because that plugin had been quietly doing all of that work. I restored it the next morning and picked a tier instead. Rebuilding Markdown's entire typography by hand to win one button is not a trade; it's a tantrum.

prose styles everything under it because that's its job. The fix was never beating it — it was deciding which elements are content, which are chrome, and telling each side its jurisdiction.

FAQ

Why don't my utility classes just win — utilities beat plugins, right?
Not reliably here. The plugin keeps its selectors low-specificity on purpose, so outcomes fall to source order and which properties each side sets. Some overrides work, some don't, and it feels random — which is why the answer is jurisdiction (the three tiers), not escalation.

Can I put not-prose on the component itself instead of a wrapper?
Yes — it's a class like any other. However, a wrapper div is just often cleaner in MDX, and remember the exclusion applies to the element and everything inside it.

Does this happen with prose alternatives / my own .markdown styles?
Identically. Any descendant-selector typography system has the same jurisdiction problem with embedded components; the three tiers apply regardless of whose plugin generated the rules.

Invalid src prop… hostname is not configured: It's One File, Not Two

Brian Bauernschmitt — Fri, 21 Aug 2026 01:52:23 +0000

---
title: "Invalid src prop… hostname is not configured: It's One File, Not Two"
published: true
description: "The next/image \"hostname is not configured\" error means your remote host isn't in remotePatterns — not your CSP. Here's the real one-file fix and why."
tags: nextjs, webdev, debugging, react
canonical_url: https://brokeinprod.dev/debugging/next-image-hostname-not-configured
---

The upload worked! The database had the real URL. The page still crashed —
because the part of Next.js that renders images had never heard of the host
the part that stores them had just used.

Start here: Add the image host to images.remotePatterns in next.config.ts (protocol, hostname, port, pathname), then restart the dev server — the config is read once, at startup. You do not need to touch your CSP — optimized next/image requests are served same-origin from /_next/image, so img-src 'self' already covers them. CSP only enters the picture if you bypass the optimizer (see below).

The setup

I was building the admin side of a portfolio site for an artist — a small CRUD panel where the website owner uploads artwork and video thumbnails instead of editing code. Uploads go to object storage (Vercel Blob), the public URL gets saved in Postgres, and the front end renders everything through Next.js's <Image> component for automatic resizing and WebP conversion.

The upload itself worked on the first try. The file landed in storage, the URL came back, and the row saved. Then the page tried to render the image and the whole thing threw a runtime error.

The symptom

Invalid src prop (https://<your-store>.public.blob.vercel-storage.com/artwork/file.webp)
on `next/image`, hostname "<your-store>.public.blob.vercel-storage.com"
is not configured under images in your `next.config.js`
See more info: https://nextjs.org/docs/messages/next-image-unconfigured-host

The important thing to notice: the upload didn't fail. Storage was fine, the database was fine — you can open the URL in a browser tab and the file is right there. This is next/image refusing to render a remote host it hasn't been told to trust: a hard runtime error, on purpose, not a broken-image icon. The error even hands you the docs link — which is genuinely the fastest path to the fix.

The diagnosis

next/image isn't an <img> tag; it's a front door to Next's Image Optimization API. By default, every image runs through the optimizer, which fetches the source server-side, resizes it, converts it to a modern format, and produces the result from your own domain. Because the optimizer makes a server-side request to whatever host you give it, an open src would be an abuse vector — an optimizer that fetches arbitrary URLs is a free proxy wearing your domain name. So Next.js requires an explicit allowlist: images.remotePatterns.

If the host of your src isn't in that list, you get the error above — before a single byte is fetched. The error is the security model working. Your job is to tell it, precisely, which hosts are yours.

One detail that catches a lot of people off guard: the match is exact and case-sensitive across every part of the URL — protocol, hostname, port, and pathname. https is not http. assets.example.com is not example.com. A too-shallow pathname (/images/ vs /images/**) fails just as hard. So if you've added the host and it still errors, you almost certainly have a part mismatch, not a missing entry.

And if a tutorial shows images.domains instead: that's the old way — deprecated since Next.js 14 in favor of remotePatterns (which can scope protocol, port, and path, where domains can't), and Next.js 16 lists it for removal in a future major version. Still works today with a warning; don't write new config with it.

The fix

Add the host to remotePatterns in next.config.ts:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "<your-store>.public.blob.vercel-storage.com",
        port: "",
        pathname: "/**",
      },
    ],
  },
};

export default nextConfig;

On recent Next.js versions there's a terser shorthand that takes a URL directly:

images: {
  remotePatterns: [new URL("https://<your-store>.public.blob.vercel-storage.com/**")],
}

Then restart the dev server — next.config is read once at startup and isn't hot-reloaded, so without a restart you'll swear the fix didn't work. Editing the config and watching the same error is the classic second act of this bug.

# stop the dev server, then:
npm run dev

Scope the pattern to your store, not the platform

A word on wildcards, because a pattern you'll see in a lot of posts is subtly wrong:

hostname: "*.public.blob.vercel-storage.com"   // don't do this

That looks account-scoped. It isn't — it matches every Vercel Blob store on the platform, including anyone else's. If someone can get a URL into your pages, your optimizer will happily fetch and serve images from a stranger's store under your domain. And the fully open hostname: "**" is worse still: it makes the error vanish and reopens the exact open-proxy problem the allowlist exists to close. Scope the pattern to the narrowest true thing — your exact store hostname and a path prefix.

One more thing about that error message: it was doing me a favor. An image
optimizer that fetches from any URL on the internet is a free proxy wearing
your domain name. The allow-list that interrupted my afternoon is the only
thing standing between "renders my images" and "renders anyone's."

The CSP twist (the part most posts get wrong)

If you run a strict Content-Security-Policy, you might expect to also add the Blob host to your img-src directive — some posts even frame this error as a "two files" fix. You usually don't have to — and here's the reasoning, because it's worth understanding rather than copy-pasting.

When optimization is on (the default), the browser never requests the Blob URL directly. It requests /_next/image?url=... from your own origin, and Next.js fetches the remote source server-side. So as far as the browser's CSP is concerned, the image is same-origin and img-src 'self' already allows it. That's why this site's CSP never listed the Blob host, yet the images rendered.

You only need the remote host in img-src when you've taken the image out of the optimizer's path:

you set unoptimized on the image or globally,
you use a custom loader that returns the remote URL,
you render it with a plain <img> tag or a CSS background-image,
or you reference it in an Open Graph / <meta> tag (those aren't next/image at all).

So the honest rule is: remotePatterns is the fix; CSP is a conditional follow-up that only applies if you bypass optimization. The two allowlists answer different questions — remotePatterns is Next's permission to fetch and optimize the image; img-src is the browser's permission to display whatever URL actually ends up in the page. With the default loader, that URL is your own origin, so the browser's question is already answered.

What I'd do differently

Set up remotePatterns the moment you wire in object storage, before the first upload — not after the first crash. It's two minutes of config that turns a confusing runtime error into a non-event. And scope the pattern to the exact host and path prefix you control; the wildcard is a smell, not a shortcut.

FAQ

The upload worked but the image won't render — why?
Different systems. Storage happily accepts and serves the file; next/image separately refuses to optimize from hosts you haven't allowlisted. A reachable URL proves nothing about the allowlist. Fixing remotePatterns doesn't touch the upload at all.

I added the pattern and it still fails. Why?
In order of likelihood: you didn't restart the dev server; or the pattern mismatches in one strict part (protocol, subdomain, port, pathname depth). If it works locally but fails in production and you've bypassed optimization (unoptimized, custom loader, plain <img>), then — and only then — check your CSP's img-src.

Can I just set unoptimized and skip this?
You can — per-image or globally — and you give up resizing, format conversion, and blur placeholders. It's an escape hatch for special cases (SVGs, tiny icons), not the fix for an unconfigured host. Note that unoptimized also puts the remote URL back in the browser's path, so a strict CSP would then need the host in img-src.

Do local images need remotePatterns?
No. remotePatterns only governs remote hosts. Images you import or serve from /public are local and exempt.

DEV Community: Brian Bauernschmitt

I Thought I Had Three Weeks of Data. One GROUP BY Said Ten Minutes.

The setup

The symptom

The diagnosis

The fix — three tiers, in order of cheapness

The rule of thumb

FAQ

Further reading

Tailwind Typography's prose Is Leaking Into Your Components — and the Three-Tier Fix

The setup

The symptom

The diagnosis

The fix — three tiers, in order

The rule of thumb

FAQ

Further reading

Invalid src prop… hostname is not configured: It's One File, Not Two

The setup

The symptom

The diagnosis

The fix

Scope the pattern to your store, not the platform

The CSP twist (the part most posts get wrong)

What I'd do differently

FAQ

Further reading