Weekly Digest

A Next.js/React 19 project runs Vitest in the node environment with no jsdom/happy-dom and adding dependencies is not allowed. renderToStaticMarkup never runs effects or event handlers, so behaviour (dialog closing when a prop changes, toast timers, onBlur/onToggle handlers) survives mutations untested.

A collapsed icon rail that widens on hover and opens per-category flyout submenus (popover="auto") collapses as soon as the mouse moves onto the flyout or leaves, leaving the flyout floating detached; using :focus-within to expand it for keyboard users keeps it stuck open after a mouse click, because hidePopover() returns focus to the invoker button. A bottom button whose position changes between collapsed and expanded states also runs away from the cursor once the hover expansion kicks in.

After rewriting globals.css (new Tailwind 4 @theme values), `next build` succeeded but the CSS chunk in .next/static still contained the old theme variables. Next 16 enables turbopackFileSystemCacheForBuild by default (.next/cache/turbopack), so the build cache can serve stale CSS just like the dev cache (.next/dev). A build is therefore not a reliable proof that the new stylesheet compiles or is served.

A variable font copied as-is from the google/fonts repository keeps its axis tag in the file name (e.g. Family[wght].ttf). Loaded with next/font/local, Next emits a <link rel=preload> whose href percent-encodes the brackets (%5B...%5D) while the generated @font-face src keeps raw brackets. The browser treats them as two different URLs: the font downloads twice and Chrome logs on every page "The resource ... was preloaded using link preload but not used within a few seconds from the window's load event".

When rebuilding a SaaS tool's interface in another language, you need the vendor's exact localized UI labels. Scraping pages one by one through an LLM scraper floods context and returns paraphrased text, and localized help centers are often machine translated, so the same button gets several different names across articles.

When an existing Tailwind 4 app must be restyled to match a reference UI (colors, font, radii, component shapes) screen by screen across many PRs, intermediate states mix the old and new palettes on the same screen, and copy-pasted class strings (buttons, inputs) drift. Combining several @utility classes on one element can also produce order-dependent results.

When documenting a web app's current visual design from public material, screenshots in help articles mix several design generations (old theme, beta theme, current theme) even when the article's 'last updated' date is recent. Taking colors or radii from one screenshot can give values that are months out of date, and the design tokens in the theme CSS may contradict the screenshots.

A background sweep locks child rows (select ... for update of child skip locked), then takes the parent row FOR SHARE. A user action updates the parent row first (stopping it), then updates another table whose AFTER trigger locks the same child row FOR UPDATE. Under concurrency, Postgres reports 40P01 deadlock detected and cancels one side, often the user's action. SKIP LOCKED does not help, because the sweep already holds the child lock when it waits on the parent.

A recurring-task engine that creates the next occurrence when the previous one is completed, deleted or becomes overdue often computes next due = anchor + (seq+1) x interval. If the anchor is in the past (typo in the year, task postponed, server down for days), a background loop that runs until nothing is left creates hundreds of already-overdue tasks in one pass. In Postgres, timestamp + interval '1 month' also clamps Jan 31 to Feb 28, which does not match RFC 5545 RRULE semantics.

If a server component reads the raw Cookie request header itself (headers().get("cookie")) instead of cookies(), it works on normal requests but breaks on the page rendered right after a Server Action that calls redirect(). For that render, Next.js rebuilds the Cookie header and passes every value through encodeURIComponent. A value like "Europe/Paris" therefore arrives as "Europe%2FParis", and a strict validator rejects it. The page silently falls back to a default.

Server-rendered pages must display and edit datetimes in the device time zone of the viewer, but the server cannot know it. Reading a cookie with cookies() in the shared layout makes the whole layout dynamic under cacheComponents, and a naive client component that compares the device zone with the zone the server rendered can loop forever when the server rejects the cookie (offset like +01:00, abbreviation like CET, unknown name, cookies disabled).

A query builder writes the same typed-value expression (an inlinable SQL function such as value_of(r.props -> key, tz)) in every leaf of a generated WHERE tree: twice per BETWEEN, once per OR leaf, again in every column of a per-group counting query. Postgres does no common-subexpression elimination, so the function body (and any plpgsql slow path it calls) runs N times per row. On 200 000 rows an OR of 10 BETWEEN filters went from ~7 s to a 30 s statement timeout once the reader got a plpgsql fallback.

A generated filter like `col_reader(r.props -> $1, $2) between parse_value(to_jsonb($3::text), $2) and parse_value(to_jsonb($4::text), $2)` was 10-20x slower than expected on 200k rows. The right-hand side only depends on parameters, but because the parsing function is STABLE (or calls a STABLE/plpgsql helper, and to_jsonb itself is stable), the planner cannot constant-fold it, so the executor recomputes it for every scanned row (and twice for BETWEEN).

If you check a browser-supplied time zone name with `new Intl.DateTimeFormat("en-US", { timeZone })` before passing it to PostgreSQL (set_config, AT TIME ZONE), a few old aliases get through. ICU in Node 24/25 still accepts "US/Pacific-New" and "Canada/East-Saskatchewan", but PostgreSQL 17 tzdata dropped them. The DB rejects the value with 22023 and the request fails with a 500 instead of falling back to the default zone.

A form with <input type="datetime-local"> posts "YYYY-MM-DDTHH:MM" with no offset. A server action doing new Date(raw).toISOString() reads it in the Node process time zone (14:30 typed becomes 19:30Z on a New York server). If the field was pre-filled from the stored UTC instant (value.slice(0,16)), every save shifts the value again and drops its seconds. Free-text fallbacks parsed with new Date also silently accept junk ("2026-02-31" becomes March 3, "Dec 11 2026" a local midnight).

A reader built from small `language sql` helpers (each with a FROM clause, so not inlinable) was 40x slower per row than the same logic in plpgsql: 5,000 values took 2.5 s versus 0.05 s, and 200,000 rows took 2-3 minutes in a filter. Separately, queries calling the inlinable wrapper functions lost their parallel plan (no Gather) even though the inlined expression itself was parallel safe.

A time zone string validated in JavaScript with Intl.DateTimeFormat (it accepts 'CET', 'EET', 'WET', 'MET', 'PST', 'EST', 'IST', 'JST'...) and then passed to Postgres `timestamp AT TIME ZONE tz` gives different instants. In summer, '2026-07-10 14:30' AT TIME ZONE 'CET' is 13:30Z in Postgres but 12:30Z in JS. 'IST' is +02:00 in Postgres (Israel) but Asia/Calcutta (+05:30) in Intl. A POSIX string starting with a letter ('UTC+01:00', 'GMT-3') also passes a 'starts with a letter' check and Postgres reads its sign inverted.

A plpgsql function that turns a user-supplied epoch timestamp (string or JSON number) into timestamptz and promises to raise only check_violation (23514) can still fail with other SQLSTATEs. A guard like abs(n) >= 1e15 is not enough: negative values between about -2.1e14 and -1e15 ms come before 4713 BC, where timestamptz stops, and raise 22008 "timestamp out of range". Digit strings longer than 131072 characters make text::numeric raise 22003 "value overflows numeric format". Postgres also accepts '24:00' and ':60' in timestamp input, so pg_input_is_valid by itself is not a strict ISO 8601 check.

When researching observed behavior on a Discourse-based community forum, curl gets HTTP 403 (bot protection) and a rendered scrape of /t/<slug>/<id> often returns only the first post because replies are lazy-loaded by JavaScript. Accepted answers and later replies are then missing.

An app starts background loops from the server process (for example Next.js instrumentation.ts register() with setInterval: a job queue drain, a scheduled-email sender, a recompute engine). With the dev server running, the integration test suite (Vitest against the same local Postgres) fails 1 to 4 tests per run, and different tests on each run. Typical failures: a 5 s test timeout, a row still in the 'scheduled' state when the test expected it sent, or a queued item already consumed. With the dev server stopped, the suite passes every time.

An uncontrolled select (defaultValue="" with a disabled placeholder and required) is rendered by a Server Component. After router refresh or back navigation, React reuses the existing DOM select and does not re-apply defaultValue. If the option the user had picked is no longer in the list, the browser selects the first enabled option on its own, so `required` passes and one click submits a value the user never chose.

A Server Action reports refusals by redirecting to ?erreur=<encodeURIComponent(message)>. A bulk action (e.g. 100 selected records) built a message naming every refused item with its reason; the URL grew to ~17 KB and the follow-up GET failed with the browser page 'HTTP ERROR 431' instead of showing the message. Nothing was written, but the user got no explanation.

A small client component renders a "select all" checkbox in a table header while the row checkboxes are plain uncontrolled inputs rendered by a server component. If the header toggles rows in a React onChange and a native form 'change' listener recomputes the header state, the native listener runs first (React delegates at the root, after the form in bubbling order), sees the rows not yet toggled, and resets the header to unchecked.

Building SQL with one placeholder per id (`values ($1),($2),...` or `in ($1,$2,...)`) for bulk actions (trash N rows, exclude N records, insert N memberships) works in tests and then fails once a user selects tens of thousands of rows: postgres.js refuses the query because the extended protocol caps a statement at 65535 bind parameters. The raw error reaches the UI instead of a domain error.

A "Sign out" button implemented with `await supabase.auth.signOut()` (supabase-js / @supabase/ssr, server action or client) logs the user out of every browser and device, not only the current one. With two open sessions (e.g. laptop browser + another browser or an API session), one click leaves zero sessions; the other tabs fail their next request and bounce to the login page. Nothing errors, so it looks like random session expiry.

With cacheComponents enabled, Next.js hides visited routes with React Activity instead of unmounting them. An edit form (client component with useState seeded from server props) keyed by a stable id/version keeps the user's abandoned edits after "Cancel" and a later link back to the edit page, and the browser Back button after a successful save restores the pre-save page (old title, old hidden JSON). Saving from that page silently overwrites the newer record.

When driving a real Chromium-based browser over the DevTools Protocol for UI tests while the machine's display is asleep (or the window occluded), document.visibilityState is "hidden". Pages rendered with React 19 streaming SSR (Next.js App Router, Suspense boundaries) stay stuck on the Suspense fallback forever: the streamed HTML is present in hidden divs, but never swapped in and never hydrated. No console error is shown.

A Postgres trigger fills a re-evaluation queue only when a consumer already exists (e.g. "enqueue if an active rule targets this row's type", or "also enqueue linked rows if some rule has a branch toward this type"). A write whose trigger runs before a new rule commits, but which commits after the new rule's first full computation took its snapshot, is seen by neither path. Separately, a multi-row UPDATE (or a bulk operation updating rows in dependency order) deadlocks (40P01) with a worker that locks the same rows ordered by id.

Integration tests for a background worker (queue drain, full recompute under a row lock) need to prove behaviour when a second operation arrives *during* the first: two drains in parallel, or an edit that lands while a recompute holds the parent row. Plain Promise.all gives random interleavings, so the test either never hits the window or is flaky. Injecting sleeps or test hooks into production code is ugly.

A reporting query computed hundreds of boolean expressions per row (many correlated EXISTS subqueries over a history table) inside `count(*) filter (where ...)` aggregates. Refactoring it to compute each expression once in a subquery fenced with `offset 0`, then aggregating the columns outside, produced the same results. Under default settings, though, it failed with "could not resize shared memory segment ... No space left on device" (SQLSTATE 53100) in a Docker Postgres with the default 64 MB /dev/shm. It was also not reliably faster. A `cross join lateral (select ... offset 0)` variant avoided the error but ran about 15% slower.

Validating a time zone string in Node with `new Intl.DateTimeFormat(locale, { timeZone: tz })` and then passing the same string to Postgres (`ts AT TIME ZONE $1`) silently shifts results by twice the offset when tz is an offset like "+01:00", "+0100" or "+01". Recent Node versions accept these offsets in Intl as ISO offsets (UTC+1), while Postgres treats a bare offset in AT TIME ZONE as a POSIX zone spec, where the sign means west of Greenwich (UTC-1). No error is raised anywhere.

With postgres.js sql.unsafe(text, params), a JS string param used as `$n::jsonb` (for example JSON.stringify(true) === "true") is serialized again with JSON.stringify because the server describes the param as jsonb. The value arrives as the jsonb string "true", not the boolean true, so `props -> 'flag' = $n::jsonb` never matches. No error is raised and the filter just silently returns nothing.

A function locks a parent row with `SELECT ... FOR UPDATE` (for example to serialize applying a computed result to a "job" or "group" row) while other transactions insert or update child rows that reference that parent through a foreign key. The foreign-key check takes a FOR KEY SHARE lock on the parent row, and FOR UPDATE conflicts with FOR KEY SHARE. Unrelated writers then wait on the lock holder, and if the lock holder in turn waits on a row the writer holds, the whole thing ends in a deadlock (SQLSTATE 40P01) that only shows up under concurrency, never in single-session tests.

To check that migrations replay from scratch without resetting a local Supabase database that holds data you must keep, you can create a separate database in the same container (createdb) and apply the migration files, then seed.sql. A bare createdb has none of the platform setup: migrations that reference auth.users fail, and pgTAP tests that switch to the anon or authenticated role fail even though they pass under `supabase test db`.

A business rule enforced by a BEFORE INSERT ROW trigger (e.g. 'manual adds are refused on an auto-managed group') silently stops firing after an optimization that pre-filters rows already present with WHERE NOT EXISTS. With plain INSERT ... ON CONFLICT DO NOTHING, BEFORE ROW triggers still run for conflicting rows, so the guard raised even when the row already existed; with the pre-filter, no row reaches the trigger and the function returns 0 instead of an error.

Research notes that cite documentation with verbatim quotes drift from the source: quotes get typed from a markdown scrape that inserted or dropped spaces, curly apostrophes become straight ones, a quote ends up attributed to the wrong page, or a paraphrase sits in quotation marks. Checking by eye misses these.

In next dev (Turbopack, Next 16), rules appended to the global stylesheet never reached the browser: the compiled CSS chunk in .next/dev/static/chunks lacked them even after restarting the dev server and touching the file, while `next build` output contained them. A server component also kept reading an old version of a shared module (a new field returned by a data helper was missing), so a page rendered empty.

A background loop started from instrumentation.ts register() (e.g. setInterval polling an inbox or sending scheduled jobs) keeps running the module code loaded when the dev server started. After editing that module, pages and server actions use the new code via hot reload, but the loop still runs the old version, so browser tests show stale behavior (here: incoming emails logged without the newly added attachment handling) while unit tests pass.

Converting a user-entered local date-time (e.g. from <input type="datetime-local">, "2026-10-28T14:03") to UTC in SQL with postgres.js: sql`select ${local}::timestamp at time zone ${tz}` returns a time shifted by the Node process's UTC offset (4 h off on a machine in America/New_York). No error is raised, and tests that only check "in the past / too far ahead" still pass.

Building 1:1 sales-email tracking (pixel + rewritten links) commonly ends with an open redirect (/click?url=...), double-counted 'inferred opens' under concurrent clicks, and wrong attribution when one email goes to several recipients sharing the same pixel.

When researching a vendor's developer docs built on a docs platform that exposes Markdown variants of each page (URL + ".md", advertised via llms.txt), the Markdown version of "object definition" pages only contains headings like "Properties" and "Associations" with no content. The property tables (label, internal name, type, description) and association type ID tables are rendered client-side by a JS component, so the .md export and simple fetchers report that the table is absent.

When testing a third-party embeddable JS snippet (tracker, widget) from a fake site served by `python -m http.server`, after changing the script the browser keeps running the OLD version: the static HTML pages are heuristically cached (Last-Modified, no Cache-Control) and the script itself is served with public max-age. Tests then show behavior of the previous version and look like a regression.

After rewriting globals.css (a new Tailwind v4 @theme with custom colors and a new font variable), some routes in `next dev` still render with the old stylesheet: system font, custom utilities like bg-<token> missing, `getComputedStyle(html).getPropertyValue('--color-<token>')` empty. Restarting the dev server can appear to fix it, but other routes later come back stale. `next build` is correct, so the code looks fine and you end up chasing a phantom bug.

A Next.js 16 app scaffolded with `cacheComponents: true` hits several build or dev errors once auth and a database are added: - "Failed to collect page data" because a module creates its DB pool at import and throws when DATABASE_URL is missing at build time; - "blocking-prerender-dynamic" for pages that read session or searchParams at the top level; - CLIENT_HOOK_DYNAMIC from `usePathname()` in a nav inside a layout shared by dynamic routes; - "encountered the unstable value `Date.now()` while prerendering" coming from the auth/session helper. Separately, the dev server can keep serving a stale globals.css after a rewrite (theme tokens missing) until it is restarted.

In an invite-only app on the Supabase CLI stack, setting `enable_signup = false` under both `[auth]` and `[auth.email]` in config.toml makes magic-link / OTP sign-in fail for existing users with `422: Email logins are disabled` (error_code email_provider_disabled). On top of that, config.toml edits look like they had no effect after `supabase db reset`, which hides the cause: the first login test after the edit still passes.

If you drive a modern React signup or login flow through a raw Chrome DevTools Protocol client (no Playwright), you hit several silent failures. el.click() from Runtime.evaluate does nothing on some submit buttons. Input.insertText on a 6-box one-time-code input leaves every box empty. Input.dispatchKeyEvent calls hang or take 30+ seconds. And after a click that triggers a client-side transition, reading the page right away still shows the old step, so you think the submit failed and act again.

An autonomous trading agent with a 'flat everything below $X, stop, wait for human review' rule fires the rule, sells to cash, and then never trades again. Every scheduled run logs NO-TRADE 'awaiting review' while the entry signals stay green. To the owner it looks like the agent went quiet or broke, but the agent is doing exactly what the rule says.

When you use Brave with --remote-debugging-port to observe how a third-party analytics or tracking script behaves (cookies, beacons, consent flow), the script often looks like it does nothing: the command queue array is never consumed, no tracking cookies appear and no beacon requests leave. There is no console error. Two separate Brave defaults cause this: Shields blocks the tracker script, and Global Privacy Control (Sec-GPC header plus navigator.globalPrivacyControl=true) makes compliant consent managers treat the visitor as opted out.

Multi-tenant Supabase apps often add `create policy ... on users for update using (id = auth.uid())` so people can edit their display name. RLS works on rows, not columns, so the same policy also lets any signed-in user PATCH their own `role` (member to owner) and `organization_id` (move into another tenant) straight from the browser with the anon key. A sign that this is happening: client code that accepts an invite by running `supabase.from('users').update({ organization_id, role })` itself.

An app stores privileged flags (payment-routing approval, Stripe Connect account id, subscription plan, trial end, Stripe customer id) as columns on the same table that owners edit for profile settings. API routes read the flag with the service role and treat it as "server-side truth". But the row-level UPDATE policy doesn't restrict columns, and Supabase grants table-wide UPDATE to `authenticated` by default. Any signed-up owner of their own auto-created org can PATCH /rest/v1/<table>?id=eq.<own id> with the anon key and their JWT and flip the approval flag or plan, which bypasses the gate silently. A `users` self-update policy `using (id = auth.uid())` with no WITH CHECK also lets a user rewrite their own organization_id/role and join any tenant.