The stream isn't broken. It's being buffered � nginx is helpfully holding the bytes so it can forward them efficiently, and for server-sent events that helpfulness is the bug. The fix is one location block, scoped so the rest of the site keeps its compression and caching. (The Node/Express side of streaming � compression middleware, flush headers � is a separate post; this one is strictly the nginx layer.)

Confirm it's buffering, not breakage

Two curls tell the whole story:

# direct to the app � tokens trickle line by line:
curl -N http://127.0.0.1:3000/api/chat

# through nginx � silence... then the entire answer at once:
curl -N https://parts.example.com/api/chat

The -N disables curl's own buffering, so what you see is what the wire delivers. Same app, same request � the difference appears exactly at the proxy. If the direct curl trickles and the proxied one dumps, you have your diagnosis: nginx is standing between your users and the tokens, collecting them first.

The one location block

location /api/chat {
    proxy_pass http://127.0.0.1:3000;

    proxy_buffering off;
    gzip off;
    proxy_cache off;

    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;

    proxy_read_timeout 1h;
}

Line by line, because each one kills a different way this freezes:

• proxy_buffering off � the main fix. By default nginx reads the upstream response into buffers and forwards it in efficient chunks. For a page, invisible; for a stream, it's a dam. Off means each event leaves the moment it arrives.
• gzip off � gzip cannot compress what it hasn't collected, so a gzipping proxy wants batches of bytes. This disables gzip for this route only. That's the part most copy-paste configs miss: you want to disable gzip for the SSE location in nginx, not for the whole site � everywhere else keeps compression.
• proxy_cache off � if a proxy_cache_path is in scope, this location must not try to store a never-ending response. Even if you think no cache applies here, an inherited zone from the surrounding server block is a classic surprise.
• proxy_http_version 1.1 + Connection "" � nginx talks to upstreams over HTTP/1.0 by default; 1.1 with a cleaned connection header is what a persistent event stream expects.
• proxy_read_timeout 1h � the quiet one. The default is 60 seconds between reads. A model that thinks before its first token, or pauses mid-generation, crosses that gap and gets cut mid-stream � the "nginx server-sent events timeout" people chase for days. Raise it for this location; an idle stream is not a stuck request here.

If you can't touch nginx: the response-header escape hatch

Docs sometimes mention X-Accel-Buffering: no � the app sends that header and nginx skips buffering for that response. It works, but it lives in the application, which is exactly the layer this post isn't about. Worth knowing it exists, because your framework's SSE helper may already send it � and if tokens still freeze with it set, the cause is usually gzip or the read timeout above.

Verify it the way you diagnosed it

sudo nginx -t && sudo systemctl reload nginx
curl -N https://parts.example.com/api/chat

nginx -t first, always � a broken config reloaded at 9 PM is a worse evening than a frozen stream. Then the same proxied curl -N from before: tokens should now trickle exactly like the direct one did. In the browser, the typing animation just comes back.

For the record, the failure-to-knob mapping:

One sentence to keep: nginx buffers because it's trying to be a good proxy � for one streaming route, a scoped location block that turns that off is the whole fix, and the rest of the site never notices.

TS2345: Argument of type '{ resolver: Resolver<FormValues, any, FormValues>; }'
is not assignable to parameter of type 'UseFormProps<FormValues, any>'.
  Types of property 'resolver' are incompatible.
    Type 'Resolver<{ title: string; slots: number }, any, { title: string; slots: number }>'
    is not assignable to type 'Resolver<FormValues, any, FormValues>'.

If you searched "zodResolver type error zod 4" and landed here, the good news is the react hook form zod 4 type mismatch almost always comes down to three causes, and you can check them in order. No generic RHF+zod tutorial below � just the version pain.

Fix 1: put the versions in the only rows that line up

Zod 4 rewrote its TypeScript surface, and the resolver package was re-typed to match. @hookform/resolvers v3/v4 were built against zod 3 � against zod 4 they produce exactly this family of hookform resolvers zod 4 errors, even when runtime behavior looks fine on small schemas.

npm i @hookform/resolvers@^5 react-hook-form@^7.55
npm ls zod @hookform/resolvers react-hook-form

Read the npm ls output, don't skim it: a second copy of zod 3 hiding under some other dependency keeps its old types in scope and re-creates the mismatch after you've "fixed" everything. If you see two zod entries, that dedupe is the fix, not your code.

Fix 2: drop the explicit useForm generics

The pattern everyone learned on zod 3:

type FormValues = z.infer<typeof schema>;

const form = useForm<FormValues>({   // ? the explicit generic is now the problem
  resolver: zodResolver(schema),
});

zodResolver(schema) already knows the exact field values it will produce, and resolvers v5 + recent RHF infer TFieldValues straight from the resolver. When you pass your own generic on top, TypeScript tries to reconcile the two � the classic zodResolver useForm generic error � and any microscopic difference (an optional made undefined-able, a default added) turns into a wall of arrows. Let the schema drive:

const schema = z.object({
  title: z.string().min(1),
  slots: z.number().int().min(1),
});

const form = useForm({
  resolver: zodResolver(schema), // field types inferred from the schema
});

type FormValues = z.infer<typeof schema>; // for handlers, still fine

Deleting code as the fix feels like a trick, but the explicit generic was duplicating information the resolver now owns. This one change clears the majority of the red after the version bump.

Fix 3: the z.coerce trap � input ? output

HTML forms hand you strings. Coercion was the standard answer:

const schema = z.object({
  slots: z.coerce.number().int().min(1),
});

Here's the trap: z.infer returns the output type (number), but React Hook Form registers and reads input values (what the DOM actually holds � string/unknown for coerced fields). Type the form as the output and the resolver's input side no longer fits:

TS2322: Type 'unknown' is not assignable to type 'number'.

For any schema where input and output differ (coerce, preprocess, transforms), use all three generics useForm accepts � input, context, output:

const form = useForm<z.input<typeof schema>, any, z.output<typeof schema>>({
  resolver: zodResolver(schema),
});

Alternatively, side-step coercion at the field level with register's built-in: {...form.register('slots', { valueAsNumber: true })} and keep the schema on plain z.number(). Both are legitimate; the three-generic form is the one that keeps validation and typing in one place, valueAsNumber is the one that keeps the schema honest about what a text input contains.

The 30-second checklist

1. npm ls zod @hookform/resolvers react-hook-form � one zod, resolvers 5+, RHF 7.55+.
2. Remove explicit useForm<...> generics; let zodResolver infer.
3. Still red? Check for z.coerce/preprocess and switch to the three-generic useForm form.

One sentence to keep: zod 4 didn't break your form � it made the resolver the source of truth, so match its version and let it do the typing. The rest of the zod 4 migration (the z.email() rename, one-argument z.record) is mechanical; this wiring is the only part that fights back.

Traceback (most recent call last):
  File "/home/shop/order-sync/sync.py", line 3, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

If you're searching "python cron job module not found" or "python script works in terminal but not cron", this is that situation exactly: same machine, same script, same user � but only cron can't find the modules. There's really one cause, one fix, and two neighboring traps that ride along with it.

What cron actually runs

Cron is not your login shell. It launches each entry with a nearly empty environment: SHELL=/bin/sh, a minimal PATH (typically /usr/bin:/bin), your HOME, and that's about it. It never reads .bashrc, .profile, or anything you've exported by hand.

Two consequences do the damage together:

1. Whatever you installed into a virtualenv is invisible, because nothing ever ran source venv/bin/activate.
2. The bare python3 in your crontab resolves through that minimal PATH to the system interpreter, whose site-packages don't contain your packages.

System Python plus missing venv equals ModuleNotFoundError, every time.

Prove it in one line

Before fixing anything, confirm which interpreter cron is really using. Drop this at the top of the script temporarily:

import sys
print(sys.executable)
print("\n".join(sys.path))

Cron mails command output to you (or your entry redirects to a log � it should). You'll see /usr/bin/python3 where you expected /home/shop/order-sync/venv/bin/python3. That mismatch is the entire bug.

The fix nobody tells you: skip activation entirely

Most threads tell you to source activate in a wrapper script. You can � but activation is optional. A venv is just a directory: a copy of the interpreter and its own site-packages, with a pyvenv.cfg beside the binary. The interpreter locates its venv from its own path, not from environment variables. Run the venv's python directly and you get the venv, no activation, no PATH setup, from any shell, service, or container.

So this is how to run a python venv in crontab without the ceremony � point the entry at the venv's own interpreter:

30 2 * * * /home/shop/order-sync/venv/bin/python3 /home/shop/order-sync/sync.py >> /home/shop/order-sync/cron.log 2>&1

One line, absolute paths, done. That version survives a server rebuild and a migration to systemd later, because it depends on nothing outside the entry itself.

The two traps that ride along

The wrong interpreter explains the import error, but a bare crontab entry tends to collect two more failures on the same night:

The hardened version handles all three:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
30 2 * * * cd /home/shop/order-sync && ./venv/bin/python3 sync.py >> cron.log 2>&1

The PATH= and SHELL= lines apply to every entry below them in the same crontab. The cd ... && guard is what keeps open("orders.csv") resolving to the file you meant.

Test it the way cron will run it

You can reproduce cron's empty environment without waiting for 2:30 AM:

env -i HOME="$HOME" SHELL=/bin/sh /bin/sh -c \
  '/home/shop/order-sync/venv/bin/python3 /home/shop/order-sync/sync.py'

env -i wipes your shell's variables, so the command sees exactly the stripped world cron provides � same PATH emptiness, same working directory rules. If it works there, it works in the crontab; if it doesn't, the error you get is the real one, not one polluted by your interactive session.

One sentence to keep: cron never activates anything � it runs /bin/sh with a scrubbed environment, so point the entry at the venv's own interpreter and use absolute paths. After that, "crontab python no module named" stops being a mystery and your 2:30 AM email goes back to being a receipt.

The five

Other threads kept running around them. I opened the hosting-pipeline thread at 10:42 PM, on Grok 4.7. The server's nginx configuration was backed up at 10:53 PM, seconds before the first name went in. I opened a thread to move WhatsMyCost onto the server at 11:31 PM and one to build the portfolio at 11:48 PM, both on Claude Opus 5.5. In another project, BurnRate tagged two betas that evening: v0.3.0-beta.13 at 10:30 PM and v0.3.0-beta.14 at 11:13 PM.

Why it went quickly

kamol.dev and every name under it already pointed at one server, and nginx turns a name into a site. What the server didn't have was a wildcard certificate. That needs DNS changes made through an API, and the server has no credential for it. So every name gets its own certificate, issued over plain HTTP, which the server already answers for any name under kamol.dev.

That makes a new name the same four steps every time: put the files in place, issue the certificate, write one server block, test and reload. The runbook lists them in that order and says not to reload after a failed test. A short, fixed list is something an agent can follow and I can check: the address loads or it doesn't, and the certificate carries the name or it doesn't.

The private names use a variant. Public DNS still sends them to the server, so their certificates renew the normal way, but there is no public HTTPS server for them. From outside my private network the connection is simply closed. WhatsMyCost runs like that because it holds admin keys for the services it tracks.

What the count leaves out

• hello.kamol.dev is a test page. It is the runbook's worked example for the static-site steps, not a product.
• kamol.dev went in as a placeholder. The portfolio this note lives on went live at 1:19 AM, outside the 71 minutes.
• For four of the names, the time is when the server block was created. For WhatsMyCost, it is when its service started. I have no log of the first request to each one.
• There is no hours-saved figure here, because I didn't measure one.

Sources

Server: creation times of the nginx files, the configuration backup and the site folders, and service start times from systemd. BurnRate: its git tags. Threads: creation times in T3 Code, the app I run the agents in.

StripeSignatureVerificationError: No signatures found matching the expected signature for payload.
Are you passing the raw request body you received from Stripe?

Search "stripe webhook signature verification failed express" and you'll find a hundred possible causes. Nine times out of ten it's exactly one: something parsed req.body as JSON before stripe.webhooks.constructEvent() ever saw the raw bytes � and in an Express app, that something is almost always express.json(). Here's why it happens, the two-line fix, and the much shorter list of suspects when the fix isn't it.

The code that produces the error

// This version fails:
app.post('/webhooks/stripe', express.json(), (req, res) => {
  const sig = req.headers['stripe-signature'];

  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body, // parsed object, not raw bytes
      sig,
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  handleEvent(event);
  res.sendStatus(200);
});

Why the signature check is so picky

When Stripe delivers a webhook, it computes an HMAC-SHA256 of timestamp + '.' + raw_body using the endpoint's signing secret (whsec_...) and ships the result in the stripe-signature header. To verify, the SDK recomputes the same HMAC on your side and compares the two. Identical bytes in, identical hash out � but if the bytes differ by a single character, the signatures don't match, and the SDK refuses to hand you the event.

The catch: an HTTP request body is a stream, and a stream can be read exactly once. express.json() reads it, parses it, and hands your route a convenient object. The raw bytes are gone by then � the SDK can't have them.

The trap that keeps people stuck for an afternoon: JSON.stringify(req.body) sometimes reproduces the original payload byte-for-byte (V8 preserves key insertion order, and Stripe sends compact JSON), so the old Stack Overflow answer of "just re-stringify it" appears to work � right up until a payload contains a number that round-trips differently (1e21 becomes 1e+21), a string that was escaped differently on the wire, or a proxy that normalizes the body in transit. You can't reconstruct the exact bytes from a parsed object. You have to keep them.

The fix: raw body on the webhook route, JSON everywhere else

Express runs middleware and routes in registration order, so give the webhook its own raw-body parser and register it before the global JSON parser:

import express from 'express';

const app = express();

// 1. Webhook route first, with its own raw parser:
app.post(
  '/webhooks/stripe',
  express.raw({ type: 'application/json' }),
  (req, res) => {
    const sig = req.headers['stripe-signature'];

    let event;
    try {
      event = stripe.webhooks.constructEvent(
        req.body, // now a Buffer of the exact bytes Stripe sent
        sig,
        process.env.STRIPE_WEBHOOK_SECRET
      );
    } catch (err) {
      return res.status(400).send(`Webhook Error: ${err.message}`);
    }

    handleEvent(event);
    res.sendStatus(200);
  }
);

// 2. Everything else still gets normal JSON parsing:
app.use(express.json());

express.raw({ type: 'application/json' }) only fires for JSON content-types, only on that route, and leaves req.body as the untouched Buffer � exactly what constructEvent wants. If the webhook route lives on a router, the same principle applies: router.post('/stripe', express.raw(...), handler).

If you can't reorder routes: capture the raw body during parsing

Some apps have a global express.json() mounted before routes that are hard to move. The parser lets you hook the buffer before it's parsed:

app.use(express.json({
  verify: (req, res, buf) => {
    // keep a reference to the raw bytes for this route only
    if (req.originalUrl.startsWith('/webhooks/stripe')) {
      req.rawBody = buf;
    }
  }
}));

app.post('/webhooks/stripe', (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.rawBody,
      req.headers['stripe-signature'],
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  handleEvent(event);
  res.sendStatus(200);
});

Same effect: the SDK gets the original bytes, and the rest of the app never notices.

When the raw-body fix isn't it

The error message tells you which failure you actually have:

Three checks that catch the remaining cases:

1. Wrong signing secret. Every webhook endpoint has its own secret. Test-mode and live-mode endpoints differ, and if you deleted and re-created the endpoint, the new one got a new whsec_... � your old env var silently stopped being right. Re-copy it from the Dashboard (Developers ? Webhooks ? your endpoint).
2. A proxy mangling things. nginx, Cloudflare or a WAF in front of the app can rewrite the body or drop unusual headers. Compare what actually arrives with what Stripe sent.
3. Testing locally with the wrong secret. stripe listen prints its own temporary whsec_... � that's the one your local server needs while testing, not the Dashboard's.

The two-minute loop to confirm the fix

stripe listen --forward-to localhost:3000/webhooks/stripe
# in another terminal:
stripe trigger payment_intent.succeeded

The CLI prints its local secret on startup, forwards the event, and shows the response code your server returned. A 200 means you're done; a 400 plus the table above points at the next suspect.

One sentence to keep: constructEvent hashes the exact bytes Stripe sent � anything that touches the body first changes the math. Give that one route the raw parser and the error stops being mysterious.