DEV Community: Shubhra Pokhariya

The Garden I Wait for Every Winter

Shubhra Pokhariya — Sun, 18 Oct 2026 12:21:49 +0000

October always makes me look at my garden a little differently.

The monsoon is beginning to fade, the mornings are changing, and I'm already thinking about winter. Not just the cooler weather, but the winter garden I want to create over the next few months.

I've started preparing some of the pots and thinking about what I want to grow. Petunias are always somewhere in my plans. I use them a lot, and I never seem to get tired of finding another place where they might work. Alyssum usually finds its way into my ideas too.

Then there are all the little decisions. Which plants would look good together? Where should the brighter flowers go, and where would a quieter combination of greenery and softer colours work better? Sometimes I've imagined an entire arrangement before I've even bought the plants. Nothing has really changed yet, but in my head, the garden is already beginning to look different.

A winter garden full of colours and little corners

I don't want every part of my garden to look the same.

Some corners can be full of petunias, with flowers spilling over the sides of their pots. Alyssum can soften another arrangement and fill the smaller spaces around other plants.

Then there are the quieter corners. I like having ferns, snake plants, and coleus around too. They aren't there to replace the winter flowers. They give the garden something to look at between the blooms, with different leaf shapes, textures, and shades of green. Coleus is especially fun when I want foliage to bring some colour of its own.

And then there is the edible side of the garden. I enjoy growing things that eventually make their way into the kitchen. Spinach and other leafy greens, radishes, carrots, lettuce, herbs, and strawberries all have their own place. They make the garden feel less like something I only look at and more like something I take part in.

I don't need every corner to do the same job. One can be bright and full of flowers, another mostly foliage, while somewhere else I might have vegetables growing in a pot that I check every morning. That mix is what makes the garden feel like mine.

Arranging plants in pots

I especially enjoy putting different plants together in one container. I don't always want a single plant sitting alone in a pot. I like combining different shapes, heights, colours, and growing habits so the arrangement changes as you look at it.

For this I like the thriller, filler, and spiller approach. Something taller gives the pot some height, fuller plants fill the space around it, and trailing plants spill over the edge. Petunias are wonderful for that last part once they start growing over the sides. Alyssum can fill smaller gaps and soften the edges, while a taller plant gives the whole pot some structure. I enjoy picturing all of that before I start planting.

Of course, plants rarely follow the picture in my head. One grows faster than another. Something needs more room than I expected. A plant that looked perfectly placed when I first arranged the pot can look crowded a few weeks later.

So I move things around.

Sometimes changing the position of one plant makes the whole pot look different. Sometimes I swap one companion for another. And sometimes the combination I didn't expect to work becomes the one I like most. That's what I enjoy about arranging pots. There's always another combination I want to try.

Between coding and gardening

Most of my working day is spent coding, and when I'm working, I like being completely focused on it. I enjoy getting deep into a problem, understanding how the pieces fit together, and staying with it until I find a solution. Gardening gives me something completely different to focus on.

When I step away from my laptop, I might go outside, look at the pots, and notice something that needs attention. An empty pot might give me an idea. A plant that has grown more than I expected might make me rethink the corner around it. Sometimes I don't even do anything. I just walk around and look.

There is a small similarity to designing something before building it in code. I think about the different pieces, imagine how they might fit together, try a few possibilities, and sometimes change the whole plan before I start.

But the garden has one rule that software doesn't: I can't make it happen faster just because I'm ready. I can prepare the soil, choose the plants, arrange the pots, and give everything the space it needs. After that, the plants take over. A petunia doesn't bloom because I'm impatient to see the final arrangement. A spinach plant doesn't grow faster because I keep checking whether it is ready to harvest.

They take their time. And I like that.

Getting ready for the season

For me, winter gardening isn't only about the garden when it is finally full of flowers. I enjoy everything that comes before that too.

There are pots to clean, soil to refresh, plants to choose, and arrangements to rethink. I get to decide what I want to try this year without knowing exactly how it will all turn out. Some combinations will work the way I imagined. Some won't.

A plant might grow in an unexpected direction. Something I thought would be a small part of an arrangement might become the thing I notice most. A simple combination might turn out better than the complicated one I spent much longer planning. Sometimes a plant just doesn't cooperate with my plan, and that's fine. I can move it, give it more space, pair it with something else, or try a different spot. The garden doesn't mind if I change my mind.

A little space to create something of my own

I've already started shaping a few corners into what I imagined. Some days I spend more time with the flowering plants. Other days I find myself looking at the spinach, the herbs, or the strawberries and noticing how much they've changed. That's one thing I love about growing so many different kinds of plants. There is almost always something happening somewhere.

Eventually, I'll come back inside, clean up, open my laptop, and return to my work. I may not come back with a brilliant new idea. Maybe I'll simply feel happy about the little corner I've started creating.

And I think that's enough.

Not everything has to become a lesson. Sometimes it's enough to step away from a screen, spend time doing something I love, and watch it grow at its own pace.

What about you? Is there something outside your work that you look forward to, even before it begins?

Your Auth Check Passed. The Agent Still Did Something Nobody Asked For

Shubhra Pokhariya — Tue, 13 Oct 2026 07:30:23 +0000

Authentication answers who. Authorization answers what they're allowed to do. Neither one answers whether this specific action was actually intended.

That's the gap I wanted to test. I built a small AI agent and tested it against several failure cases before I got to a result I was confident in. I'm including that part too, because pretending everything worked on the first try would be its own kind of false claim.

Disclosure: Arcjet commissioned this article. I chose the angle, wrote the code, and ran the tests independently. Arcjet reviewed the technical outline for factual accuracy, not the conclusions.

The authorization gap in AI agents

Earlier in this series I made the case that a Server Action isn't a function call, it's a public POST endpoint wearing a convenient syntax. That post was about who can reach the action and whether they're allowed to. This one is about a question a model changes entirely. Once a model is deciding whether to call that action, being "allowed to" stops being the whole story.

A human clicking a button is one kind of signal. A model generating a tool call from the contents of a document is a different kind of signal, and none of the checks from that earlier post, not the ownership check, not the role check, not the proxy in front of it, were built to tell the two apart. That's not a flaw in that post's argument. It's a different question the three-layer model was never asked to answer.

The setup

I built a small Next.js research assistant. It reads a document, summarizes it, and if the document mentions filing an expense, it calls a fileExpenseReport tool to do it. Nothing fancier than that on purpose. I wanted the security behavior easy to reason about, not buried under unrelated complexity.

The stack: Vercel AI SDK, Gemini as the model, Arcjet's Guard SDK wired in at two separate points:

import { launchArcjet, detectPromptInjection } from "@arcjet/guard";
import { guardTool } from "@arcjet/guard/vercel-ai/v7";

detectPromptInjection screens the inbound document before the model ever sees it. guardTool wraps the actual tool call. They're two separate enforcement points answering two different questions, not one check doing double duty. Collapsing them into a single check is the mistake this whole piece is about, so I kept them apart on purpose.

Everything below is real output from my own account. Synthetic accounts, synthetic data, real Arcjet decisions. The "database" is a stub that logs each insert to the console, so a "database write" here means a call to that stub.

The legitimate baseline

First run: a normal document, a normal expense, nothing adversarial. The model read it, called the tool, and the database write went through. That's the control case, the thing that has to keep working while everything else gets locked down.

Attack one: the obvious injection

Next, I planted a document with a direct embedded instruction, something that told the agent to file an expense to an account nobody had actually asked about. detectPromptInjection caught it and denied the request before the model ever got a turn. The Arcjet dashboard showed the same event independently, marked PROMPT_INJECTION, sitting among otherwise clean entries.

One thing from an earlier, less finished run of the same fixture: the injection got past detection once, and the model declined to act on its own. I'm not counting that as a security control. A model refusing to do something today doesn't mean it refuses tomorrow, and treating good judgment from an LLM as your actual security boundary is exactly the mistake I built this whole test to avoid making.

A planted document is the version I actually built and tested, but it's one instance of a broader category. The same gap opens whenever the content driving a decision comes from somewhere the user didn't type it themselves, an email thread the agent summarizes, a page it scrapes, the output of a previous tool call feeding into the next one. I only have real results for the document case. I'm not going to claim I tested the others.

Attack two: the one that actually mattered

The obvious injection is the easy case. The interesting one is the paraphrased version, no "ignore previous instructions," no imperative override, just the same underlying request phrased like an ordinary business note.

detectPromptInjection let it through. The model attempted the tool call. And the action boundary, a plain allow-list check inside the tool's own execute() handler, rejected the account and left no database write behind.

That contrast is the center of the piece. Detection and authorization answer different questions. A detector asks: does this content look suspicious? The tool boundary has to ask something else entirely: should this specific call, with these specific arguments, actually run right now? A clean detection result doesn't answer that second question, and building your security around the assumption that it does is how paraphrased attacks get through.

Authorize the AI tool call before the side effect

The check that stopped this particular attack is deliberately boring: a plain application-level allow-list inside the tool's own execute() function. Worth being precise here since it's easy to conflate the two: guardTool is the Arcjet wrapper around the tool call, and the allow-list below is my own application logic. It only runs once a call has already gotten past guardTool, sitting immediately before the database write as its own separate, deterministic check.

if (!ALLOWED_ACCOUNTS.includes(input.accountId)) {
  return {
    denied: true,
    boundary: "action",
    reason: "account_not_allowed",
    message: `Account ${input.accountId} is not on the allow-list`,
  };
}

I return a structured result instead of throwing. The function exits before the database write, and the result gives the model a clear explanation for the denial. If the model retries, the same allow-list check runs again.

No exotic API, no clever abstraction. That's the point. The check doesn't need to be sophisticated. It needs to sit in the right place: after detection, after the model's decision, immediately before the side effect.

A tool call is a proposal from the model. A successful side effect is a decision made by the application. Those are not the same event, and treating them as the same event is exactly how a clean-looking request turns into an unauthorized database write.

Re-running the full matrix

I confirmed the pattern held across the rest of the set: a benign document with imperative-sounding language that shouldn't trigger a false positive, and it didn't, no tool call attempted at all. A clean document with an ambiguous instruction, no injection pattern present anywhere, still denied at the action boundary. That last one matters on its own, it proves detection alone wouldn't have caught it, because there was nothing for a detector to catch.

Why the usual layers don't close this gap

None of this replaces a proxy, a WAF, or RBAC. It's not a substitute for any of them. But it's worth being precise about what each one actually answers. A proxy or WAF sees a clean, authenticated POST request. RBAC correctly returns yes, this user is allowed to file expenses. Neither has any visibility into whether this particular call, with these particular arguments, was something the user actually intended. They're solving a different problem, and they solve it well. They just don't solve this one.

The remote-policy detour

I also tested Arcjet's remote policies, which Arcjet documents as a way to change enforcement logic centrally without redeploying the application.

The first runtime attempt didn't work cleanly. A config mismatch on my end needed fixing before the policy behaved as intended.

With that corrected, and the local allow-list temporarily expanded so it couldn't be the thing making the decision, the same running application produced two results:

Allowed account, policy in Live mode: the model called the tool with the account the policy explicitly permits, Arcjet returned ALLOW, and the database write happened.

Denied account, same code, same deployment: the model called the tool with a different account, and the response came back DENY, reason INPUT_CONSTRAINT, no error, no fallback behavior, a genuine policy match. Nothing wrote to the database.

That's what I wanted to verify with the remote policy: the decision about which accounts are allowed lived in Arcjet, not in my application code. The same running server, with no code changes, allowed one account and denied the other based on a policy I manage centrally. Per Arcjet's docs, editing that policy changes enforcement without a redeploy, though the SDK caches policies and rechecks them every few minutes, so changes are not instantaneous. I didn't test a policy edit between runs.

Tool call is not the same thing as executed

This is worth stating on its own, because it's the core claim the whole article rests on. When you check whether a tool call happened, you're checking whether the model attempted something. That's not the same as checking whether the underlying action executed. A denied call can still show up as a tool call in your logs. In my test, it never reached the database write. The same distinction matters for whatever consequential operation your tool actually performs, whether that's a database write, an external API call, an email, or a payment. If your logging conflates those two things, you can end up believing a security check is working when it's actually just recording attempts, not outcomes.

If a denied call still shows up in your logs, it's worth deciding upfront what you actually want recorded at that point:

{
  toolCall: "fileExpenseReport",
  decision: "DENY",
  boundary: "action",
  reason: "account_not_allowed",
}

Structuring it this way means an attempted-and-blocked call is unambiguous in your own telemetry, not something you have to reconstruct later by cross-referencing tool-call logs against database writes.

PII is a different boundary

Prompt-injection detection and authorization don't solve the same problem as sensitive data leaking to a model or a downstream tool call. If a document contains an email address, a phone number, or a government ID, checking the model's response is already too late, the data has already crossed the provider boundary.

I didn't run a real test of this as part of this project's matrix, so I'm not presenting one as an experiment result. But it's worth naming precisely rather than skipping past it, because the boundary is different from everywhere else in this piece. It's not right before a side effect, it's wherever sensitive data is about to leave the application's control at all, a document going to the model provider, a tool output feeding back into model context, a value about to appear in a log.

Arcjet's Guard SDK also provides local sensitive-info detection for agent and tool paths, so detection can happen in-process before sensitive content crosses another boundary. Detection tells you something sensitive is present. Redaction lets the model continue without the original value. Blocking is the right call when the value should never leave the application at all.

Automated traffic is a separate concern

One more boundary worth mentioning, because it answers a genuinely different question than everything above. I sent a real curl request to a small API route using the same Arcjet HTTP-boundary client, then sent the same request with its User-Agent changed to look like a normal browser. Both were denied as bots. Changing only the User-Agent didn't change the result. I can't say precisely which signals contributed to that decision, so I'm not going to guess at the mechanism.

I'm keeping this separate because it's a different question. An authenticated, authorized, perfectly legitimate-looking request can still be automated and abusive at volume. Request-level bot detection and rate limiting belong at the HTTP boundary, alongside the application-level checks, not instead of them.

Where this pattern doesn't help

A legitimately authorized user asking for something genuinely bad isn't caught by any of this. That's not a prompt-injection problem, it's a business-authorization problem, and it's still squarely your application's responsibility to define who's allowed to do what.

And the model's own judgment is not something to lean on as a security control, however good it looks in a given run. I saw a model decline to act on a bad instruction in one run and comply with an equivalent instruction it hadn't seen worded that way in another. That's exactly why the check needs to live in code that runs the same way every time, not in whatever the model happens to decide.

Runtime enforcement isn't free either. Each additional check adds processing and operational complexity, and remote policy evaluation introduces another dependency that needs explicit failure handling. The right tradeoff depends on how consequential the operation is and how much latency the application can tolerate.

What the experiments actually proved

Test	Result
Legitimate request	Tool called, database write succeeded
Obvious injection	Denied by detection, corroborated in the dashboard
Paraphrased injection	Passed detection, denied at the action boundary
Benign content, imperative language	No tool call attempted
Clean content, ambiguous instruction	Denied at the action boundary, with no injection pattern present
Remote policy, allowed account	Evaluated, allowed, wrote to the database
Remote policy, denied account	Evaluated and denied by the remote policy, with no database write
Real automated request	Denied as a bot; changing the User-Agent did not change the result

A practical pattern

If you're building anything where a model can trigger a consequential action, put an explicit, application-level check immediately before that action for anything in this category:

money movement
deleting data
changing permissions
sending external communications
refunds
production changes

Authentication and authorization should still happen upstream, same as always. This check isn't a replacement for either. It's a specific, narrow boundary sitting right in front of the operation that actually causes harm if it's wrong.

Before an AI agent can cause a side effect

Is the user authenticated?
Is the user authorized for this resource?
Is content influencing the model treated as untrusted?
Is the tool call independently authorized?
Are the actual tool arguments checked, not just the fact that a call happened?
Does denial happen before the side effect?
Can sensitive data leave the application?
Can automated traffic reach the endpoint repeatedly?
Have you verified that a denied call produces no side effect, not just a log entry?

The model doesn't own the security boundary

Authentication tells you who's asking. Authorization tells you what they're generally allowed to do. Neither one tells you that this specific action, generated by a model, from content it read somewhere, was actually something anyone intended. That check belongs at the action itself, checked in code that behaves the same way on every run, not inferred from whether the request looked clean upstream or whether the model seemed to behave reasonably this time.

Put the boundary where the side effect happens. Everything else is a proposal until then.

I Built an AI Gardening App That Tells Me to Put the Laptop Down

Shubhra Pokhariya — Sun, 11 Oct 2026 12:54:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Coding is my thing. Gardening is a part of who I am.

I have hundreds of pots, and I know my plants through the little things they show me. I notice which ones respond well to buried banana peels, which seem happier with used tea granules or old buttermilk, and which need my lunch-box system instead of raw kitchen scraps buried around them. I watch their leaves, new growth and flowers.

I do not need an app to tell me how to care for my own plants. That understanding comes from spending time with them. But it made me think about how a tool could help someone who is still learning to notice these things.

For a long time coding and gardening lived in different corners of my day. I would code for hours, then walk away from the screen to be with my plants, and the two never really met. This challenge gave me a reason to put them in the same room. So first, thank you to the DEV team and everyone behind it. You gave me the opportunity to write code about the thing I love most, and I enjoyed every hour of it.

The question I almost asked an AI

On 30 September I moved my marigold out of a shady, bright corner and into the open sun. The corner was there to keep the heavy rain off it. It grew from a cutting of a plant that came up by itself from last year's seeds, so it already feels a little like family.

On 5 October I counted about three open flowers and three buds. On 9 October I counted seven open flowers and five buds.

My first thought was to ask an AI why.

An answer would have been easy to get and easy to believe. But the sun, rain and time passing had all played a part, and I couldn't tell which one made the difference. Neither could an AI. So I asked a different question. Not "why is my plant doing this?" but "what should I look at before I change anything?"

That question became Garden Trials.

What I Built

Garden Trials is a small app that runs entirely on your own computer. The whole idea fits in one line, which is look first, change one thing, let the garden answer.

I do not like screens near my plants. When I am with them I want my hands in the soil and my phone away. Sometimes a bloom looks so good that I click a photo, for myself and for other plant lovers. So I built the app the way I wish gardening tools worked. It talks to me before and after, and in the middle it asks me to put the laptop down and go and look.

I write a note about a plant and the day I saw it. A local Gemma model reads it into plain facts.
The app asks me to check one specific thing on the plant. Until I write down what I found, it will not suggest anything.
I either watch, or pick one change from a small fixed menu, ideally leaving a similar plant alone to compare.
I count and take a photo. The app shows me the last photo so I can match the angle.
I get a table, a chart, a verdict, an evidence level from 0 to 3, and one plain next step.

It is not a plant doctor. It never says what is wrong with a plant, and it never says what caused a result.

Garden Trials is for gardeners who are still learning to read their plants, and for anyone who wants to check their assumptions rather than jump to conclusions. It brings observations, follow-up checks, simple experiments and evidence tracking into one process. Instead of just recording what happened, it helps gardeners look at what changed, what else might have affected the result, and what their observations can actually tell them. It is not meant to replace the understanding that grows from spending time with plants, but to encourage closer observation.

Demo

The quickest way in is the sample garden. Tick "Try the illustrative sample garden" in the sidebar and you can walk through the whole loop with made-up plants. Nothing from it is ever saved to a real garden.

Code

shubhrapokhariya / garden-trials

Local Gemma 3 1B app (Ollama + Streamlit) that sends gardeners back to their plants to look first, helps them test one change at a time, and assigns each result an evidence level from 0 to 3.

🌱 Garden Trials

Look first. Change one thing. Let the garden answer.

A small local app for gardeners. A Gemma model running on your own laptop helps you write down what you see and asks one thing to go and check on the plant. Plain Python builds the experiment, keeps the records and works out how much the evidence really shows. The app never says what caused a result.

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

Demo video (48 seconds, no sound): https://youtu.be/Rm7X4btlZVk

Quickstart

Install Python 3.11 or newer and Ollama. The tests were run on Python 3.11.
Download the code, then in its folder run:

python -m pip install -r requirements.txt
ollama pull gemma3:1b
python -m streamlit run app.py

On Windows you can double-click run.bat instead. On macOS or Linux, run bash run.sh. Both scripts still start the app if Ollama is missing…

View on GitHub

Setup is in the README: Python 3.11 or newer, Ollama, ollama pull gemma3:1b, then python -m streamlit run app.py. The folder examples/my-garden/ holds my real notes, counts and photos from this week. Start the app with GARDEN_DIR=examples/my-garden and you can read them without touching your own data.

My real garden, this week

Petunia

On 7 October I counted two open flowers, one spent flower, four buds and a lot of tiny buds forming. I took photos and counts on 7, 8, 9 and 10 October, but I only opened the app on the 10th, so I typed the first three days in afterwards. The app marks those entries as backfilled, which is exactly what they are. It is also why the trial says it started on 10 October.

When I saved the 7 October note, Gemma's reading dropped a number, so the app threw the reading away and kept my words exactly as I wrote them. Then Gemma's Look First question turned out to be about pests or disease, which I had never mentioned. The app blocked it and asked its own question instead:

Count the open flowers and the buds right now. Do the newest shoots have buds?

I went and looked on the 10th. Four open flowers, two bright ones on top and two darker ones lower down that had just opened, and small buds at the tips of the shoots.

Date	Open flowers	Buds	Note
7 Oct	2	4	Front view. One spent flower not counted.
8 Oct	2	4	Removed the spent flower. Photo from above.
9 Oct	2	4	Buds clearly bigger and longer.
10 Oct	4	2	Two buds opened. Bright sun, so the reds look brighter.

I removed one spent flower on the 8th. That was routine upkeep, not a test, but I want to say so. There was no comparison plant, and petunia buds open on their own anyway. The app gave this evidence level 0 and said it plainly. No change was made during these counts, so it shows what the plant did while I watched and says nothing about a cause.

The two new flowers opened darker and more velvety than the older ones. I read that a new petal is still small and tightly folded, so its colour is packed close together, and that as the flower opens fully and stretches out, the same colour spreads over a bigger petal and looks lighter. So I guess that is what I am seeing.

Marigold

The 5 October photo was taken for myself, not for the trial. I clicked it just because the plant looked lovely, from the side, and only later decided to use it here. One bud is partly cut off at the edge. The 9 October photo is the one I took for the trial, from above, where every flower and bud can be seen. My first count may have missed buds I could not see from the side, so the jump from 3 to 7 open flowers is in my notes, but it is not a fair comparison. A few petals also looked flattened after some rain. The rain may be the reason, but that is a guess.

Bougainvillea

Five cuttings, about a month and a half old, in the same soil and the same small black nursery bags on the same bench. One of them already has two pink flowers and the other four have none. Its mother plant is in full bloom, while my other bougainvilleas are only starting. My guess, not tested, is the variety or the time of year. The cuttings are different varieties, so "same soil, same bench" is not a fair test. A real test needs cuttings of the same variety, taken at the same time from different mother plants.

How I Built It

The stack is small on purpose: Streamlit, one JSON file, and gemma3:1b running locally through Ollama. I picked the 1B Gemma model to find out whether this idea works on an ordinary laptop with no cloud account. On a laptop CPU an answer can take up to a minute.

Gemma has three jobs. It reads my note into plain facts, suggests one thing to go and check, and picks one change from a short menu. Everything that has to be reliable lives in plain Python, because I treat the model's output the way I would treat any untrusted input.

If a number from my note is missing in Gemma's reading, the reading is rejected and my exact words are kept.
Details Gemma adds that I did not write are removed by a word-match check. It is a loose check, so it can miss some.
The cause field is forced to "unknown" in code.
Pest and disease questions are blocked unless I raised them first.
Trials come from a fixed menu that is filtered per plant. "Water more" is never offered for bougainvillea, which likes to stay on the dry side.
Verdicts and evidence levels are calculated by code, never by Gemma. Level 3 needs two finished trials of the same change, each with a comparison plant and nothing else changed, all pointing the same way.
Saves go to a temporary file first and are then swapped in. A garden file that cannot be read is moved aside and never overwritten.

The tests replace Gemma with fake and deliberately bad answers, such as garbage, dropped numbers, invented pests, off-menu picks. A second set drives the real pages end to end. There are 85 tests, and none of them needs Ollama.

What went wrong

The model did not behave in my own garden. Gemma's reading of all three of my notes was rejected by the number check, and one of its three questions was blocked.

The other two questions got through, and they were generic. "Is the plant's stem straight?" had nothing to do with what I was seeing, so I wrote down what I actually noticed. The guards block invented pests. They cannot make a small model's question a good one. They also only catch the failures I thought of, and the checks match English words, so notes in Hindi are not checked the same way. In my real garden Gemma only read my notes and wrote Look First questions. Both of my real trials were watch-only, so it never picked a trial there.

Why Does Open Innovation Matter?

Gemma runs on my laptop through Ollama. There is no API key, no usage bill and no cloud AI call. My notes and photos sit in a folder on my own machine, and the photos are saved without their location data. Setup needs the internet once, to download the packages, Ollama and the model, and I switched off Streamlit's anonymous usage statistics.

Running Gemma locally let me build and test this idea without an API key and without paying for every request. I could try it as often as I liked, and if a better small model arrives, I change one setting (OLLAMA_MODEL) and the rest of the app stays as it is. The small model had clear limitations, which I describe above, but that was part of what I wanted to learn, which is how far an open model can take this idea on an ordinary laptop, with ordinary code checking its output. The experiment showed me both the value of running a model locally and the limits of relying on its answers.

What I took away

The point of the app is what happens when I close the laptop. It asks me to go and look, and I stand there with the plant and nothing else. It cannot tell whether I really went outside, and I will not pretend it can. That pause is a promise I make to myself.

The AI can suggest what to look at. The garden gives the answer.

Thank you for reading, and thank you again to the DEV team for a challenge that let me bring the two things I love together.

Prize Categories

Best Use of Gemma

Aborting a Fetch Doesn't Stop Your Node.js Server. Here's What Does.

Shubhra Pokhariya — Tue, 06 Oct 2026 08:47:00 +0000

I fired 20 requests at a Node.js handler and made every client walk away after 100 ms. The handler was five steps of 200 ms each, so 100 steps of work in total if nothing got cancelled.

Nothing got cancelled. The server finished 100 of 100 steps for clients that were already gone.

Then I taught the handler to notice the disconnect. Same 20 abandoned requests, and this time it ran 0 of 100 steps.

If your frontend calls controller.abort() when a user switches a filter, your backend may be doing the same thing right now. The client-side abort is real, but it doesn't automatically reach the work your server is doing. I wanted to know exactly where it ends, so I tested node:http, Express 4 and 5, Hono and a real PostgreSQL database. Node 22.22.2 and 24.21.0, pg 8.23.1, PostgreSQL 18.4, HTTP/1.1, everything on localhost. I used Node's built-in fetch as the client, not a browser.

Three results surprised me:

node-postgres accepted a { signal } option and silently ignored it.
req.signal exists on Node 24 and is undefined on Node 22, with no warning.
Sending the Postgres cancel through your normal pool can hang it.

Where the cancellation stops

client        abort() -> fetch rejects, connection closes
server        sees a closed socket
your handler  keeps running
fetch to      keeps running
another API
SQL query     keeps running

Only the first two lines happen on their own. Everything below them is code you have to write. A synchronous CPU loop is a special case, and I'll get to it near the end.

What the server sees when a client aborts

I wrote a handler with five 500 ms steps and aborted from the client at 1200 ms:

[1216ms] client: abort()
[1223ms] client: caught AbortError
[1225ms] server: res 'close' (writableEnded=false, destroyed=true)
[1548ms] server: step 3/5 done (socket.destroyed=true)
[2562ms] server: step 5/5 done (socket.destroyed=true)
[2567ms] server: res.end() called, no error thrown

The client was done in 7 ms. The server noticed something, because the response emitted close. But the handler is just an async function, and nobody told it to stop. Steps 3 to 5 ran against a dead socket, and res.end() didn't even throw.

How to detect a client disconnect in Node.js

Listen for close on the response. The Node http docs say ServerResponse emits it when the response finishes or when the connection drops before that. Inside the handler, check res.writableFinished to tell the two cases apart. It was true after a normal response and false after an abort.

I skip the request's close event. It also fired on disconnect in my runs, but the docs only promise it means the request was completed, and I don't want to build on something that isn't guaranteed.

This is the helper I ended up with. It merges "the client left" with a server-side deadline:

export function requestSignal(res, { timeoutMs } = {}) {
  const gone = new AbortController();
  res.once("close", () => {
    if (!res.writableFinished) gone.abort(new Error("client closed request"));
  });
  const signals = [gone.signal];
  if (timeoutMs) signals.push(AbortSignal.timeout(timeoutMs));
  return AbortSignal.any(signals);
}

Pass the result to anything that takes a signal:

const signal = requestSignal(res, { timeoutMs: 600 });
const r = await fetch(upstreamUrl, { signal });

When the client left at 200 ms, my API stopped and the downstream request closed early. With the 600 ms deadline, the client got a 504 and the downstream request closed early too. signal.reason tells you which case you're in: a TimeoutError for the deadline, or your own error for a disconnect. In an earlier run with a hand-wired controller, the cancel travelled from the client through the API to the downstream service in about 25 ms.

Two details that cost me time:

Create the timeout signal inside the request. AbortSignal.timeout() starts counting when you call it, so a module-level one expires once and then fails every request.
AbortSignal.timeout() rejects with TimeoutError, not AbortError. If your catch only checks for AbortError, timeouts slip through. Check e.name.

AbortSignal.any needs Node 20.3 or 18.17, and AbortSignal.timeout needs 17.3.

Does Express have req.signal? It depends on your Node version

Recent Node versions give IncomingMessage a built-in signal. Here is what I saw:

Node 22.22.2, node:http, Express 4.22.3 and 5.2.1: req.signal is undefined.
Node 24.21.0, same setups: it exists, and the handler stopped when the client left.
Hono 4.13.12 with @hono/node-server 2.1.3: c.req.raw.signal fired on both Node versions.

The Node docs list req.signal as added in 24.16.0 and 26.1.0. There is a catch for the versions right after that. On 24.16 to 24.19 and 26.1 to 26.6, the signal can abort after a perfectly normal request finishes, which makes it unreliable for spotting a real disconnect. The fix landed in 24.20.0 and 26.7.0. If you run something in between, upgrade or test it yourself.

The Node 22 case is the sneaky one. sleep(ms, null, { signal: req.signal }) passes undefined, runs without any cancellation and throws nothing. The res 'close' helper above behaves the same on every version I tried, which is why I kept using it.

Does aborting a fetch stop a running Postgres query?

No. I ran select pg_sleep(3) in a handler, aborted the client at 500 ms, and asked Postgres from a second connection what was still running:

[ 917ms] api: client left
[1227ms] DB: active pg_sleep queries 300ms after client left = 1
[3494ms] api: query finished normally

Postgres kept working for about 2.6 seconds after the client left. With a real report query, that means a held connection, wasted CPU and sometimes held locks.

node-postgres ignores the signal option

The API shape makes this tempting:

await client.query({ text: "select pg_sleep(2)", signal });

With pg 8.23.1, the query ran for 2009 ms and nothing was thrown. I also searched the installed pg, pg-pool and pg-protocol code and found no AbortSignal handling. Proposals exist in the node-postgres repo, but none of that was in the version I tested. So this is about pg 8.23.1 only. It fails silently, so you only catch it by testing.

How to cancel a Postgres query with pg_cancel_backend

What worked was asking Postgres to cancel the running statement from a different connection, because the busy one is stuck inside the query:

// the cancellation part only, not a complete handler
const signal = requestSignal(res, { timeoutMs: 5000 });
const client = await pool.connect();
const { rows: [{ pid }] } = await client.query("select pg_backend_pid() as pid");

signal.addEventListener(
  "abort",
  () => cancelPool.query("select pg_cancel_backend($1)", [pid]).catch(console.error),
  { once: true }
);

await client.query("select pg_sleep(3)"); // rejects with code 57014 when cancelled

[5256ms] api: pg_cancel_backend sent
[5257ms] api: query error -> 57014 canceling statement due to user request
[5570ms] DB: active pg_sleep queries 300ms after client left = 0

I left the rest of the handler out on purpose, because a half-finished copy of it is worse than none. The full handler, plus the Node 22 vs 24 screenshots, is in my longer write-up. The version I ran on Node 22 and 24 with Express 4.22.3 and 5.2.1 also does these things:

It uses a separate pool for cancels. With a work pool of 2 and two abandoned requests at once, I reproduced a hang. Both connections were held by handlers waiting on a cancel that needed a free connection.
It checks signal.aborted right after the pid query. If the deadline already fired, the listener above never runs. The client is still waiting, so the handler answers 504 itself.
It removes the listener and awaits any in-flight cancel before client.release(). Otherwise the connection can go back to the pool mid-cancel.
It catches 57014 and reads signal.reason. That code only means "cancelled". A deadline, a disconnect, statement_timeout or a DBA can all cause it, and the answer should be 504 only for the deadline.
It replies only if !res.destroyed && !res.writableEnded and sends everything else to next(err), since Express 4 doesn't catch rejected async handlers.
Both pools have on("error") handlers. Without them, one dropped idle connection can crash the process.

Treat the cancel as best effort. pg_cancel_backend returning true means the signal was sent. The Postgres protocol docs say a cancellation might or might not have any effect, for example when it lands after the query already finished, and the client can't directly tell which happened. With a pool, only cancel while your request still owns the connection. It also does nothing for a session sitting idle in a transaction, since there is no running statement.

Aborted doesn't mean undone

I ran a transaction that did an INSERT, spent one second on slow work, then COMMIT, and let the client leave at 300 ms. The naive handler committed an order for a user who was long gone. The cancel-aware handler caught 57014 and rolled back, so no row was written. The cancel only interrupts the statement. The rollback is yours to write.

The mirror image happens on the client. If you abort a POST, you can't know whether the server processed it, and a blind retry can create a duplicate. Put idempotency keys on anything with side effects.

You don't have to wait for the client to leave, either. Postgres has statement_timeout, and with 300 ms it raised 57014 after 307 ms. That covers the opposite problem, clients that never disconnect.

The limit: a blocked event loop can't be cancelled

JavaScript can't interrupt code that is already running. I ran a 1000 ms synchronous loop inside a handler and aborted the client at 200 ms. The server couldn't process the disconnect until the loop ended, and by then res.writableFinished was true. Node had written the response into a socket it hadn't yet noticed was closed, so even my own check couldn't tell the client had left.

If the work blocks the loop, there is nothing to cancel. Move it to a worker thread, or cut it into chunks with an await between them.

What I didn't test

Drivers other than pg, HTTP/2, reverse proxies and load balancers (a proxy may or may not tell your upstream that the client left), browsers, Deno and Bun.

Four rules I'd ship with

Treat a disconnect as an event. Listen for close on the response, check writableFinished, and pass one signal to everything that accepts it.
Cancel database work yourself when the driver won't. Check whether yours honors { signal } before you trust it, and keep cancels on their own pool.
Put a deadline on every request with a per-request AbortSignal.timeout() plus statement_timeout.
Make side effects safe. Roll back on cancel and use idempotency keys for retries.

The scripts behind every number are in a GitHub repo, if you want to rerun them.

I only tested pg. If you've checked how mysql2, Prisma or another driver treats an abort signal, tell me what you found in the comments.

React 19 useFormStatus Returning False? I Built a SubmitButton That Fixes It

Shubhra Pokhariya — Tue, 29 Sep 2026 08:13:20 +0000

A few weeks back I wrote about the useFormStatus bug that got me the hardest, the one where pending sits at false forever because the hook was called in the wrong component. If you haven't read that one, the short version is this: the hook only reports on a parent form, never one rendered by the same component calling it, and nothing warns you when you get it wrong. No error, no console message, the button just quietly never enters a pending state.

That post explained the bug. This one is about what I actually built once I got tired of re-explaining the same fix to myself on every new project, and about a second version of that exact same silent failure I didn't notice until I'd already shipped the first fix.

One scope note before the code: this fixes the placement mistake. If pending is false because the form submits through a plain onSubmit handler that only calls preventDefault(), or through a URL string action, moving the hook won't change anything, because there is no Action for it to track.

What the first post didn't cover

Moving the hook fixes the placement bug, but I ran into two more problems as soon as I used it in real forms.

The first is disabled={pending} on the button itself. It works, and it's also the wrong choice if you care about keyboard users. A disabled element drops focus the instant it becomes disabled. Someone tabs to your submit button, hits Enter, and focus jumps away mid submission, sometimes landing nowhere useful at all. The fix is aria-disabled instead of disabled, with the click blocked manually so repeat submissions still get ignored.

function SubmitButton({ children, pendingText, intent }) {
  const { pending } = useFormStatus();

  function handleClick(e) {
    if (pending) e.preventDefault();
  }

  return (
    <button
      type="submit"
      name={intent ? "intent" : undefined}
      value={intent}
      aria-disabled={pending || undefined}
      aria-busy={pending || undefined}
      data-pending={pending ? "" : undefined}
      onClick={handleClick}
    >
      {pending ? pendingText : children}
    </button>
  );
}

Focus stays exactly where it was. Style the pending state off aria-disabled or data-pending, not :disabled, since the native attribute is never actually set here.

The second problem shows up once a form has two submit buttons. pending belongs to the whole form, not to whichever button was clicked, so a Save Draft and a Publish button next to each other both light up for one click. The browser already knows which button submitted. Its name and value are in the FormData, so you read them back out and compare.

function useFormStatusForIntent(intent) {
  const status = useFormStatus();
  const submittedIntent = status.data?.get("intent");
  const isThisIntentPending =
    status.pending &&
    (intent === undefined || submittedIntent == null || submittedIntent === intent);
  return { ...status, isThisIntentPending };
}

<form action={savePost}>
  <textarea name="body" />
  <SubmitButton intent="draft" pendingText="Saving draft...">Save Draft</SubmitButton>
  <SubmitButton intent="publish" pendingText="Publishing...">Publish</SubmitButton>
</form>

The button shown earlier is simplified to keep the focus on aria-disabled. In the full file, SubmitButton calls this hook, so only the button someone actually pressed shows pending. One gotcha before you wire this up: pressing Enter in a text field submits through whichever button comes first in the markup. That's the HTML spec's definition of the default button, not something React decides. Put your safest action first.

Locking the rest of the form while it submits

Next you'll probably want the rest of the form locked while the request is in flight, so nobody edits a field mid submit. A native <fieldset> does this in one line instead of one disabled prop per input.

function PendingFieldset({ children, unstyled }) {
  const { pending } = useFormStatus();
  return (
    <fieldset
      disabled={pending}
      style={unstyled ? undefined : { border: 0, margin: 0, padding: 0 }}
    >
      {children}
    </fieldset>
  );
}

The unstyled flag is for CSP. The inline reset removes the fieldset's default border, but a CSP that blocks inline styles ignores it on server-rendered HTML and the border comes back. If that's you, pass unstyled and style it with a class.

One trade-off: a focused input loses focus when the fieldset disables it, the same thing that happens to a disabled button. Use it where blocking edits matters more than keeping focus.

For a screen reader announcement, aria-busy alone isn't read out loud. You need an actual live region for that.

function FormStatusText({ pendingText, idleText = null }) {
  const { pending } = useFormStatus();
  return (
    <span role="status" aria-live="polite" aria-atomic="true">
      {pending ? pendingText : idleText}
    </span>
  );
}

The bug I didn't catch until the second pass

Here's the part that made me go back and touch the file again after I thought it was already done.

SubmitButton had a dev-only check from the start. Render it outside a form and you get a console error in development explaining why it won't work.

PendingFieldset and FormStatusText had the identical requirement, "must be rendered inside the form", written right there in their own comments, but neither one actually had the check. Misplace either one and it fails as silently as the original bug: the fieldset never disables, the status message never appears, and nothing warns you.

It's an easy mistake to make, since these two feel less important than the submit button and tend to get dropped in wherever is convenient.

Both now run the same placement check the button already had, with the same escape hatch for anyone using a portal on purpose:

<PendingFieldset unsafeSkipFormCheck>
  {/* rendered through a portal: outside the form in the DOM, inside it in the React tree */}
</PendingFieldset>

The check has a limit. It only looks at the DOM, but useFormStatus follows the React tree. A component rendered through a portal can track the form correctly and still trigger the warning, because in the DOM it isn't inside the form. That's what unsafeSkipFormCheck is for.

Where this landed

The full file has the button, the fieldset, the live region, the intent hook, and the placement check on all three components. One file, no dependencies beyond react and react-dom.

Known limits: intent doesn't work with a per-button formAction, form.requestSubmit() skips the click guard, and two synchronous clicks in the same task both get through before React re-renders. I've only tested in Chromium and Firefox so far. Safari and screen readers are still untested.

If you want the whole thing: useFormStatus SubmitButton. Free, single file.

If you're catching this one first and want the full explanation of why the original bug happens, that's the earlier post.

React 19's useTransition Looked Simple. Then I Found a Second Bug Hiding Inside the First One

Shubhra Pokhariya — Mon, 21 Sep 2026 15:32:13 +0000

Every hook in this series so far has been a passenger. useActionState rides inside a Transition and reports back the result. useOptimistic rides inside one and shows you a preview before the real answer lands. useFormStatus doesn't even ride, it just reads a status from whoever else is driving. useTransition is the only one of the four that sits in the driver's seat by itself, no form required, no other hook required.

That's also why it's the easiest one to get partially right. You wrap a click handler in startTransition, you get an isPending flag, everything looks fine in your browser tab, and you ship it. Then someone double-clicks fast, or your function throws, or you try to hook it up to a text input, and the parts nobody mentioned start showing up.

This is a standalone guide. If you're new to this series, everything below works on its own. If you've read Part 4, you already saw useTransition make a brief appearance there through a wishlist button.

I tested every example below against React 19.2.8. I also re-ran the race condition, error boundary, and overlapping Transition checks on React 19.3.0, which shipped on September 9.

What useTransition Actually Gives You

Call it at the top of a component and you get back exactly two things, always in this order.

import { useTransition } from "react";

function ProductFilters() {
  const [isPending, startTransition] = useTransition();
  // ...
}

isPending is a boolean. It becomes true at the first call to startTransition, and stays true until every Action in that Transition, including anything you awaited, has completed and the resulting state is shown. startTransition is a function that takes one argument, a function of your own, and runs it right away. Nothing about startTransition is delayed or scheduled for later. What changes is how React treats any set call that happens while your function is running, those updates get marked as low priority and interruptible instead of urgent.

That's the entire contract. No result value, no built-in error state, no queue. Compare that to useActionState from Part 1, which hands you back whatever your function returns as state. useTransition doesn't do that. If your function returns something, that return value is simply gone unless you store it yourself. This is the tradeoff for using useTransition directly: less structure, but nothing standing between you and the raw mechanism.

A Search Filter That Doesn't Freeze the List

Forms and buttons aren't the only place a Transition earns its keep. Filtering a long list as someone types is a case useActionState was never built for, there's no side effect to run, no single result to track, just a rendered list that needs to stay responsive while it re-renders on every keystroke.

One precision point before the code: startTransition does not make a computation run in the background. The function you pass to it runs immediately and synchronously, right when you call it. What gets marked as low priority and interruptible is the state update, and the render that follows from it, not whatever JavaScript happens to run inside the callback before that update fires. That distinction is the whole point of this example, so the two state variables below are split around it deliberately.

import { useState, useTransition } from "react";

function ProductSearch({ products }) {
  const [query, setQuery] = useState("");
  const [filterQuery, setFilterQuery] = useState("");
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    const value = e.target.value;
    setQuery(value);

    startTransition(() => {
      setFilterQuery(value);
    });
  }

  const filtered = products.filter((p) =>
    p.name.toLowerCase().includes(filterQuery.toLowerCase()),
  );

  return (
    <div>
      <input
        value={query}
        onChange={handleChange}
        placeholder="Search products"
      />
      <ul style={{ opacity: isPending ? 0.6 : 1 }}>
        {filtered.map((p) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </div>
  );
}

query drives the input and updates synchronously, so typing never lags. filterQuery is the one wrapped in startTransition, it "lags behind" query on purpose. filtered isn't stored in state at all, it's a plain expression computed fresh on every render from filterQuery. The key point: the products.filter() call itself still runs as an ordinary, uninterrupted piece of JavaScript, exactly like it would outside a Transition. What changed is when that render happens and whether a more urgent update, another keystroke, is allowed to cut in front of it. React isn't chunking your array iteration, it's deciding whether the render containing that iteration gets to proceed right now or gets pushed behind something more urgent.

This is also where the input-in-a-Transition limitation becomes concrete instead of abstract. You cannot wrap query itself in startTransition, only filterQuery can go there. A controlled input's value has to update synchronously with every keystroke to feel correct, and React's own troubleshooting docs name this exact two-state split as one of two fixes, the other being useDeferredValue on a single state variable.

When to reach for useDeferredValue instead. The rule of thumb is about who owns the set function. Here, the component owns setFilterQuery directly, so useTransition is the right tool. If ProductSearch instead received its query as a prop from a parent, or read it from some other hook you don't control the setter for, there'd be no set call of your own to wrap in startTransition. That's exactly the case useDeferredValue exists for, you hand it the value, const deferredQuery = useDeferredValue(query), and it produces its own lagging copy without needing access to whoever's setting the original. Same lagging behavior, different entry point depending on whether you're driving the update or just receiving the value.

The await Rule, and Why It Actually Happens

Part 4 showed the pattern for handling state updates after an await inside a Transition, wrap them in a second startTransition call. What it didn't get into is why React needs that second call at all, and that's worth understanding once instead of memorizing as a rule.

function handleSave() {
  startTransition(async () => {
    const saved = await saveDraft(draft);
    // this update is NOT part of the Transition
    setStatus("saved");
  });
}

React marks a set call as part of a Transition by checking a flag while your function is running synchronously. The moment your function hits await, execution yields back to the JavaScript engine, and that flag is gone by the time the code after await resumes. React has no way to know that resumed code is a continuation of the same Transition rather than something unrelated. This is a JavaScript limitation, not a bug React chose not to fix, the language doesn't yet give React a way to track "this async continuation belongs to that earlier synchronous scope." A TC39 proposal called AsyncContext would close this gap, but it isn't part of the language yet.

The fix is the same nested call every time.

function handleSave() {
  startTransition(async () => {
    const saved = await saveDraft(draft);
    // ✅ back inside a synchronous startTransition scope
    startTransition(() => {
      setStatus("saved");
    });
  });
}

After every await, state updates that need to remain part of the Transition must be wrapped in another startTransition, as the useTransition docs describe. Two sequential awaits in one Action means two separate re-entries into startTransition for the updates that follow each one.

Pending UI With No Form in Sight

Every pending indicator earlier in this series read isPending from useActionState or pending from useFormStatus. useFormStatus reads from a parent form, and useActionState is built around the Actions you dispatch through it. useTransition's isPending is the one you get when you start the Action yourself, with no form involved. It's just a boolean tied to whatever you wrapped, which means it works for things that were never going to be a form to begin with: a favorite toggle, a sort order change, a modal that loads data before it opens.

function SortButton({ label, sortKey, onSort }) {
  const [isPending, startTransition] = useTransition();

  return (
    <button
      disabled={isPending}
      onClick={() => startTransition(() => onSort(sortKey))}
    >
      {label}
      {isPending && <span className="spinner" aria-hidden="true" />}
    </button>
  );
}

The button that triggered the change is the one that shows its own pending state, without a global loading flag and without prop drilling a status down from somewhere else. That's the same locality useFormStatus gave you in Part 3, just reached through a different door, one that doesn't require a <form> to walk through.

Errors in a Bare Transition

This is the gap Part 4 didn't touch, and it's a real one. useActionState gives you a place to catch expected errors as returned state. A bare useTransition call gives you nothing like that. If the function you pass to startTransition throws, there's no result state to inspect, the throw propagates up to the nearest error boundary instead.

import { useTransition } from "react";
import { ErrorBoundary } from "react-error-boundary";

function AddToCartButton({ productId }) {
  const [isPending, startTransition] = useTransition();

  function handleClick() {
    startTransition(async () => {
      const result = await addToCart(productId);
      if (!result.ok) {
        throw new Error("Could not add item to cart");
      }
    });
  }

  return (
    <button disabled={isPending} onClick={handleClick}>
      Add to Cart
    </button>
  );
}

export function CartButtonWithBoundary(props) {
  return (
    <ErrorBoundary fallback={<p>Something went wrong adding this item.</p>}>
      <AddToCartButton {...props} />
    </ErrorBoundary>
  );
}

Worth being clear about what's actually happening here: useTransition doesn't give you a custom error state or a new API surface for errors, that part is true. But it's not accurate to call this identical to any ordinary render-time error either. React specifically added Error Boundary support for Actions, so a throw inside startTransition gets caught the way a throw in a plain event handler normally wouldn't, event handler errors have never been something a boundary catches on their own.

Two things trip people up here. First, the error boundary has to wrap the component calling useTransition, not just the button markup, an error boundary placed below the hook call won't catch anything. Second, this is an all-or-nothing tool: a thrown error takes down whatever the boundary wraps until the user or your code resets it. If you want a recoverable, inline error message instead of the whole section replaced by a fallback, don't throw, return an error value from the function and store it in state yourself. useActionState gives you that pattern for free, since its return value becomes state automatically. Plain useTransition doesn't, you'd be rebuilding a small piece of what useActionState already does.

The Race Condition Nobody's First Draft Handles

Here's the scenario Part 4 flagged and left open. A user clicks something that triggers an async Transition, changes their mind, and clicks again before the first request resolves. Both requests are now in flight. The response that arrives last is the one the component keeps, even if it belongs to the earlier click.

import { useState, useTransition } from "react";

function QuantityStepper({ itemId, initialQty }) {
  const [qty, setQty] = useState(initialQty);
  const [isPending, startTransition] = useTransition();

  function updateQty(next) {
    startTransition(async () => {
      const saved = await updateCartQuantity(itemId, next);
      startTransition(() => {
        setQty(saved);
        // if a slower, earlier request resolves after this one,
        // its setQty runs last and the stale value wins
      });
    });
  }

  return (
    <div>
      <button onClick={() => updateQty(qty - 1)}>-</button>
      <span>{qty}</span>
      <button onClick={() => updateQty(qty + 1)}>+</button>
    </div>
  );
}

React's own reference material for this exact scenario says it plainly: Actions inside a Transition don't guarantee execution order once you await something, because the async boundary loses that ordering context the same way it loses the Transition flag. useActionState sidesteps this for its own dispatcher by queuing calls and running them one at a time, but a raw useTransition call gets no such protection.

There's actually a second problem hiding in this code, and it's easy to miss because it looks like the same bug. updateQty(qty - 1) reads qty from the render that produced this particular click handler, and setQty only fires once the network request resolves. Click + twice within that window, before the first request's response has actually come back and updated qty, and both clicks compute their next value from the same starting number, sending the same result twice instead of incrementing twice. This isn't a same-tick React batching quirk, clicks are handled as separate events and React doesn't merge them. It's simpler and more common than that: the state genuinely hasn't changed yet, because the only thing that changes it is still sitting on the wire. Fixing the request race doesn't fix this one, they need separate solutions.

import { useState, useTransition, useRef } from "react";

function QuantityStepper({ itemId, initialQty }) {
  const [qty, setQty] = useState(initialQty);
  const [isPending, startTransition] = useTransition();
  const requestedQty = useRef(initialQty);
  const latestRequestId = useRef(0);

  function updateQty(delta) {
    // authoritative next value, independent of what's currently rendered
    requestedQty.current += delta;
    const next = requestedQty.current;
    const requestId = ++latestRequestId.current;

    startTransition(async () => {
      const saved = await updateCartQuantity(itemId, next);

      startTransition(() => {
        // only apply this result if nothing newer has been fired since
        if (requestId === latestRequestId.current) {
          setQty(saved);
        }
      });
    });
  }

  return (
    <div>
      <button onClick={() => updateQty(-1)}>-</button>
      <span>{qty}</span>
      <button onClick={() => updateQty(1)}>+</button>
    </div>
  );
}

Two separate fixes doing two separate jobs. requestedQty is a ref that tracks the next value to send independently of the rendered qty, so it keeps accumulating correctly across rapid clicks no matter how far behind the actual render is. latestRequestId is the token that solves the original problem, a stale response checks whether it's still the most recent request before it's allowed to apply. A ref is the right tool for both because neither one needs to trigger a render on its own, they just need to survive across renders and stay current. This isn't the only way to solve the ordering half, an AbortController tied to each request works too if your fetch layer supports cancellation, though aborting only stops the client from waiting, and the server may already be processing that mutation. The token check needs nothing from your API beyond what you probably already have.

Two limits worth knowing. requestedQty advances at click time, so it assumes the server accepts the requested value as sent. If the server clamps or normalizes that value, the ref and qty can drift apart. The request token only decides which response can update the UI. It doesn't cancel the earlier request or guarantee that the server applies the updates in the order they were sent.

When to Reach for useTransition and When Not To

Reach for it when you need pending tracking for something that isn't a form submission and doesn't need a tracked result value: filtering, sorting, tab switches, toggles, navigation.

Don't reach for it for a controlled input's own value, that has to stay synchronous or typing will visibly lag. Don't reach for it when you need the function's return value as state, that's what useActionState captures automatically and useTransition doesn't. Don't reach for it assuming request ordering is handled, it isn't, not without the token pattern above or an equivalent.

Keep in mind that the useTransition reference still lists a limitation: if multiple Transitions are ongoing, React currently batches them together. React 19.3 changed something nearby. According to the React 19.3 release post, a Transition with a slow render no longer holds up unrelated ones. So don't assume several pending indicators settle independently.

Where This Leaves the Series

You need to...	Reach for
Own a form's result and pending state in one place	`useActionState`
Show finished UI before a server response confirms it	`useOptimistic`
Read a form's pending state from a component that isn't managing it	`useFormStatus`
Run pending-tracked work outside a form, with full control yourself	`useTransition`

Part 4 called these four answers to four different questions sharing one mechanism. Having now used the fourth one without any of the other three in the room, that framing holds up. useTransition isn't the beginner-friendly entry point of the group, it's the one with the fewest guardrails, which is exactly why it's also the one that can do things the form-shaped hooks were never built for.

I went through the out-of-order version of this bug in a plain search box in I Throttled My App to Slow 3G. Here's What My Tests Never Caught.

So which one have you already shipped without knowing it, a response landing out of order or two fast clicks reading the same stale value? Drop it below.

The Code I Couldn't Leave Alone

Shubhra Pokhariya — Thu, 17 Sep 2026 12:20:21 +0000

The bug report was simple enough. On the reports dashboard, if you changed the date range while a filter was already active, the page number didn't reset. So a user could end up on page 4 of a report that now only had one page of results, staring at an empty table with no idea why.

I found it fast. The pagination state and the filter state were living in two different places, useState in the table component and useSearchParams for the filters, and nothing was watching one to reset the other. I added a useEffect that reset the page to 1 whenever the search params changed. It was the smallest change that unbroke the dashboard, and I wasn't about to restructure the component tree for a twenty minute fix. Tested it locally, clicked through a few filter combinations, watched the empty table problem disappear. Twenty minutes, maybe less.

I didn't open the pull request yet. I told myself I wanted to read through the diff once more before pushing.

That's when I actually looked at ReportFilters.tsx for the first time in a while, and I didn't love what I saw. The filter state existed in two places at once. Some of it lived in the URL through useSearchParams, which is what actually drove the API call, and some of it lived in local component state that only existed to control what the dropdowns displayed. Most of the time they matched. Occasionally, if you clicked fast enough, they didn't, and you'd see a dropdown showing one filter while the table quietly fetched with another. Nobody had filed a bug for that. I don't think anyone had ever managed to click fast enough to notice.

But I'd noticed it now, and once you've seen a bug like that, it's hard to unsee it. It reminded me of a race condition I once tracked down in a checkbox that looked right on screen while the requests behind it quietly disagreed, the same kind of mismatch between what the UI shows and what actually happened. Different bug, same shape.

So I pulled the local state out entirely and made the URL params the single source of truth, reading everything through useSearchParams and writing through router.replace. That's a real fix. Two sources of truth for the same data is exactly the kind of thing that eventually causes a much worse bug than the one I'd started with. I felt good about that change, and I still do.

While I was in there, I noticed the filter logic itself, the actual function that turned the search params into a query object, was duplicated. It existed once in the component to build the fetch request, and again inside app/api/reports/route.ts to validate incoming params on the server. Same logic, written twice, slightly out of sync, because someone had updated one copy when a new filter type was added and forgotten the other. I pulled it into a shared lib/filters.ts and imported it in both places. That's not a nice to have. That's the kind of drift that can quietly turn into a production bug.

At this point I'd fixed the original bug, removed a genuine duplicate source of truth, and closed a real gap between client and server validation. If I'd stopped there, this would just be a normal Tuesday. I didn't stop there.

Once the filter logic was centralized, I looked at the route handler again and thought, well, since I'm already reading through this, the report data itself doesn't actually need to be client fetched at all. It's not interactive in any way that requires it. It could be a server component, fetched directly with the filters coming from searchParams in the page props, no client-side fetch, no loading spinner, no waterfall. In my head it looked roughly like this.

export default async function ReportsPage({
  searchParams,
}: {
  searchParams: Promise<{ range?: string; status?: string }>;
}) {
  const { range, status } = await searchParams;
  const reports = await getReports({ range, status });
  return <ReportsTable data={reports} />;
}

That's a bigger change than a bug fix. It touches the page structure, it means rethinking how the table gets its data, it means the loading state disappears entirely because the server just renders with the data already there.

I started doing it anyway.

I got about halfway through converting the table to a server component before I stopped, not because it was going badly, but because I glanced at the git diff panel in my editor and the file count had gone from one changed file to seven. Seven files, for a bug that was, structurally, a missing line inside a useEffect.

I sat there for a second looking at that number, and the question that actually stopped me wasn't "is this too much work." It was smaller and quieter than that. I asked myself whether the server component conversion was something the product needed right now, or whether it was something I wanted to do because I could see exactly how to do it and it bothered me to leave it undone once I'd seen it.

I didn't have a clean answer immediately, which is honestly what made me pay attention. The filter state fix and the duplicated logic fix, I could justify those in one sentence each, to myself or to a reviewer. The server component rewrite took a full paragraph to justify, and most of that paragraph was about how satisfying the final version would be, not about what was currently broken for anyone using the dashboard.

That's usually the tell, I think. Not the size of the change. Plenty of small changes are indulgent and plenty of large ones are necessary. It's how long the justification takes, and who the justification is actually for.

So I split it. I finished the bug fix and the shared filter logic, wrote a focused pull request that a reviewer could read in five minutes and understand completely, merged it the same day. The server component rewrite went into its own branch with its own description, explaining what it would remove, what it would simplify, and why it was worth doing on its own terms instead of riding in quietly behind a one-line bug fix. It's a good change. I still believe that. It just needed to stand on its own, reviewed and evaluated as what it actually was, instead of hiding inside something smaller.

What stays with me isn't that I almost shipped too much. It's how reasonable every single step felt while I was inside it. Nobody would have blinked at any individual commit. The dropdown desync fix, obviously worth doing. The shared filter util, obviously worth doing. Even the server component conversion, on its own merits, was obviously worth doing. Stacked together in one sitting, driven by one bug report, they stopped being a response to a problem and became a response to my own discomfort with leaving the file the way I found it.

I don't think that discomfort is something to train out of myself. It's most of why I'm good at this. Being able to see the second problem while you're fixing the first one is a real skill, and I'd rather have it than not. But seeing a change and shipping a change used to be the same motion for me, and somewhere in that two hour stretch I finally felt the gap between them instead of just hearing about it in theory.

I closed the laptop that evening having shipped exactly one thing, a twenty minute bug fix with a real structural improvement folded honestly into it. The bigger rewrite is sitting in review on its own branch, where it belongs, where someone can actually look at it and ask whether it's worth the seven files, instead of me deciding that alone at ten at night because I couldn't stand leaving a route handler half server, half client, one more day.

I Throttled My App to Slow 3G. Here's What My Tests Never Caught

Shubhra Pokhariya — Tue, 15 Sep 2026 05:41:21 +0000

I wasn't looking for a performance problem. I wanted to see what happened when the network got slow enough that assumptions I normally never notice had time to surface. So I opened DevTools, set the throttle to 3G (Chrome's network throttling reference dropped the separate "Slow 3G" preset a while back and just calls it "3G" now, sitting between Slow 4G and Offline), and started clicking around an app that had never once misbehaved on my normal wifi.

Two things broke. Both were correctness bugs, not "feels slow" complaints, and both were sitting in code that had passed every test I'd written for it.

Bug one: a race condition, search results arriving in the wrong order

The app has a search box. Type a query, it fetches results, it shows them. Nothing fancy:

async function search(query) {
  const res = await fetch(`/api/search?q=${query}`);
  const data = await res.json();
  setResults(data.results);
}

This is a race condition, and on fast wifi you'll rarely notice it, because request and response times are close enough together that ordering rarely flips. That's not a guarantee, it's just what low, consistent latency looks like most of the time. Slow the connection down and that stops holding. If you type "apple", pause, then quickly change it to "banana", the "apple" request and the "banana" request are both in flight at once. Whichever one happens to take longer, maybe it hit a slower part of the network, maybe the server did more work for it, can land after the other one. When it does, its response overwrites the screen with results for a query you're not even looking at anymore.

If this sounds familiar, I went through a close cousin of this bug in The Optimistic UI Race Condition That Only Showed Up on the Fifth Click, stale results from out-of-order requests aren't unique to search boxes, they show up anywhere a component fires more than one async request over its lifetime.

The 3G throttle on its own makes this easier to hit, since it throttles every request in the session regardless of which path it takes. But it doesn't guarantee a flip on any given run, so to make it reproducible for this post I forced it deterministically: I gave the two queries different artificial delays on the server, apple takes 3 seconds, banana takes 200 milliseconds. That's a server-side delay, not the network throttle. For the logs and timings below, I ran the test with throttling off so the numbers are clean and come from the server delay alone. With throttling on, the same race still happens, but the network adds less predictable latency on top, which makes the timing harder to read in a screenshot.

Click apple, then banana right after.

sent request for "apple"
sent request for "banana"
got response for "banana" after 210ms
got response for "apple" after 3001ms

The screen ends up showing apple's results, because that's whichever response arrived last, not whichever request the user cared about last.

The fix is to stop trusting arrival order and start tracking which request is actually the latest one:

let latestQueryId = 0;

async function search(query) {
  const thisId = ++latestQueryId;
  const res = await fetch(`/api/search?q=${query}`);
  const data = await res.json();
  if (thisId !== latestQueryId) return; // a newer request has already been sent
  setResults(data.results);
}

Same two requests, same order of arrival, one result on screen:

sent request for "apple" (id 1)
sent request for "banana" (id 2)
got response for "banana" (id 2) after 210ms
got response for "apple" (id 1) after 3001ms
   IGNORED: a newer request has been sent since this one fired

Another option is AbortController, which can abort the previous fetch when a new query starts. That's a different tradeoff from request IDs, not the same mechanism wearing a different name. Aborting stops the client-side fetch from continuing to wait on that response. It doesn't necessarily stop the server from finishing the work it already started. Tracking request IDs instead lets the old request finish, then explicitly ignores its response if it's gone stale. I went with request IDs here because the search endpoint is cheap and I didn't need to cancel anything server-side, just make sure a late response can't win.

Bug two: the autosave that saves twice, or drops your last edit

This one comes from a client-side timeout that assumed a round trip would always be fast.

The autosave gave up and retried if it hadn't heard back within 1.2 seconds, a reasonable number if saves normally take a few hundred milliseconds. On a throttled connection a save can genuinely take two or three seconds without anything actually being wrong. The client can't tell "slow" apart from "failed." It just knows the timer ran out, assumes the worst, and fires a second save while the first one is still in flight and about to succeed on its own.

save #1 sent
save #1 client-side timeout, treating as failed and retrying
save #2 sent
save #1 confirmed (arrived after the retry already fired)
save #2 confirmed

Two saves for one edit. If the save endpoint isn't strictly idempotent, that's two writes that can produce different results depending on what changed in between, not just a harmless duplicate.

My first fix was a simple in-flight guard: skip firing a new save while one is already out. That stops the duplicate, but it introduces a different bug. If you edit again while a save is in flight, that edit gets silently dropped instead of ever being sent:

user types "hello", save #1 starts
user types "hello world" while save #1 is still in flight
   skipped (save in flight), edit "hello world" is dropped
save #1 confirmed: "hello"

For this autosave behavior, the version you want doesn't skip the newer edit, it queues it and sends it right after the current save finishes:

let saveInFlight = false;
let pendingContent = null;

async function save(content) {
  if (saveInFlight) {
    pendingContent = content;
    return;
  }
  saveInFlight = true;
  try {
    await postSave(content);
  } finally {
    saveInFlight = false;
  }
  if (pendingContent !== null) {
    const next = pendingContent;
    pendingContent = null;
    await save(next);
  }
}

The try/finally matters here, not just style. Without it, if postSave ever rejects, saveInFlight stays true forever and every future edit gets silently queued and never sent. That's a worse bug than the one you started with, because it fails quietly.

save #1 sent: "hello"
skipped (save in flight), queued latest: "hello world"
save #1 confirmed: "hello"
save #2 sent: "hello world"
save #2 confirmed: "hello world"

No duplicate requests, and the latest edit still gets saved. (If you edit again while that queued save is itself in flight, it just replaces pendingContent again, that's the coalescing working as intended, only ever the most recent edit waits in line.) This is the simple version of the queueing strategy, worth saying plainly: a production autosave also needs an explicit policy for what happens when a save actually fails, not just when it's slow. This code handles slow, not failed.

The actual lesson here isn't "guard against duplicate saves", it's that a client-side timeout only tells you a response hasn't arrived yet. It doesn't tell you what happened on the server, and if the operation has side effects, retrying it needs an explicit strategy for what happens to work that's already in flight.

What both actually have in common

I didn't go looking for two bugs about ordering and timing specifically. I went looking for whatever would show up if I stopped assuming my network was representative of anyone else's. Both of these surfaced because each one was built around an assumption that happened to hold on my machine and broke somewhere else. Responses usually arrive in the order you send them, until they don't. A couple seconds is usually enough time for a save to complete, until it isn't.

Neither of my test suites caught either of these, because neither ran on a slow connection. They ran on the same fast, forgiving network I was developing on, which is exactly the network that hides both of these bugs. Same pattern I ran into with a completely different upgrade in Next.js 16 Broke My App in 4 Places and None of Them Threw an Error, none of these bugs throw, none of them fail loud, they just quietly do the wrong thing until you go looking under the exact condition that triggers them.

If your code assumes responses arrive in request order, or treats a client timeout as proof of failure, you likely have a version of one of these sitting in code you already trust, whether or not you've seen it misbehave yet.

I Tested generateStaticParams in Next.js Cache Components. My Layout Broke Twice

Shubhra Pokhariya — Wed, 09 Sep 2026 12:22:33 +0000

The last post here got picked apart in the comments in the best possible way. @nazar-boyko asked the sharpest version of the question I'd skipped entirely: if the ids are known at build time, does the page go fully static, or does Cache Components still want a stream, cache, or block answer regardless. @mudassirworks flagged the nested-component wrinkle, two server components independently awaiting params, and where the Suspense boundary actually has to sit. @suraj09, @glenallen, and @merbayerp circled the same architecture question from different angles, what happens once a layout and the page underneath it both depend on the same runtime data. @alexshev pushed on something none of us had done, turning a one-off fix into something that survives after the post is forgotten. None of it had a real answer from me at the time, so I built a fresh project and went and got one.

So I built a fresh test project, four routes this time instead of one, and ran every one of these to an actual answer.

Does generateStaticParams make a route static?

Short version: no. I gave a route three known ids up front and left the data access unguarded, same as the original test.

export async function generateStaticParams() {
  return [{ id: "1" }, { id: "2" }, { id: "3" }];
}

export default async function ProductStaticPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id);
  // ...
}

Build fails, and it names id 1 specifically, one of the exact three I told it about ahead of time. Knowing the id at build time and being allowed to skip the stream, cache, or block decision are two different things.

That part's a clean answer, but not the interesting one. The interesting part is what happens once you actually pick a fix, because the two fixes I tried don't produce the same result.

Wrap the data access in Suspense, and the build passes, but all three known ids come out marked as Partial Prerender. The data stays deferred behind the static shell, the same as it does for an id the route has never seen. Swap that for caching the data function instead, one word changed, "use cache" instead of a Suspense wrapper, and those same three ids flip to fully static, baked into the build output.

That's the real answer to Nazar's question. generateStaticParams decides which paths get attempted. Whether they end up static depends on the work the route performs for those params and how that work gets handled, not on the ids being known ahead of time by itself.

One more dead end worth flagging before you go looking for it yourself: I tried pairing generateStaticParams with the old dynamicParams = false option, expecting a 404 for anything outside the known set. dynamicParams still exists as a route segment config in Next.js generally, but it's disabled specifically once cacheComponents is on, so the build rejects it instead of applying it. In this Cache Components setup, unlisted ids are handled at request time instead.

The bug that took three attempts

This is the one I'd read even if you skip everything else, because it's the part that answers Suraj, Glen, and Mustafa's question, and it's the part that actually surprised me.

Setup: a layout and a page sharing a route segment, both reading the same id, both calling the same two data functions. Both unguarded. Build fails, expected.

My first move was the obvious one: fix the page, leave the layout alone, since I'd already handled the page's own component.

Still failed. Fixing the page did nothing for an unguarded params access in the layout above it. A Suspense boundary in the page can't reach back and cover work that already happened in the parent before the page even rendered.

So I fixed the layout too, wrapped the component reading the data in its own Suspense, the same move that had worked everywhere else so far.

Still failed. Same error. This is where I stopped guessing and ran next build --debug-prerender to get an actual trace instead of a route name.

It pointed at const { id } = await params;, sitting in the layout, above the Suspense boundary I'd just added. Not the data fetch inside the wrapped component. The line that produced the id in the first place.

I'd wrapped the component that used the id. I hadn't wrapped the line that produced it.

The real fix passes the whole params promise down and resolves it inside the wrapped child, instead of resolving it in the parent and handing over a plain value:

async function WorkspaceHeader({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const workspace = await getWorkspace(id);
  return <header>{workspace.name}</header>;
}

export default function WorkspaceLayout({
  children,
  params,
}: {
  children: React.ReactNode;
  params: Promise<{ id: string }>;
}) {
  return (
    <div>
      <Suspense fallback={<header>Loading...</header>}>
        <WorkspaceHeader params={params} />
      </Suspense>
      <div className="p-8">{children}</div>
    </div>
  );
}

That builds clean. Same principle applied to the page underneath it.

One negative result worth keeping, since it's the mistake I'd expect someone to reach for first on a real app: I also tried leaving both layers completely unguarded and just caching the two shared data functions instead, assuming that would cover both callers at once. It didn't touch the failure at all. The unguarded operation was never the data fetch, it was await params itself, sitting outside any boundary in both places. Caching a function a broken access calls doesn't fix the access that calls it.

Mudassir's nested-sibling case turned out to follow the same underlying rule, just one layer shallower: two independent components both reading params, and wrapping only one of them left the other exposed. The fix isn't a specific boundary shape, it's making sure nothing reading runtime data sits outside every boundary, whether that's one shared wrapper or several separate ones.

What I'd actually check on a real app

Audit layouts before pages. A layout's unguarded access fails on its own terms, independent of anything you've already fixed below it, and it's the thing most likely to get missed because layouts don't feel like "the route" the way a page does.

When a fix doesn't work and the error still points at something you've technically wrapped, check where the await itself happens, not just where the result gets used. Resolving a promise above a boundary and passing the plain value into a wrapped child still counts as an unguarded access.

Alex, on the regression test question, here's what I landed on: a small script that rebuilds, then hits each fixed route including the unlisted-id case, since a plain build won't catch that on its own. Worth being honest that an HTTP check only proves the route responds, not which rendering mode it's using. That classification only ever comes from the build output itself.

I put the full four-route walkthrough, all the build screenshots, the exact debug trace, and the regression script in the full Next.js generateStaticParams and nested-layout walkthrough if you want the whole thing end to end rather than the condensed version here.

Has anyone hit this layout-versus-page split in a real production route tree yet? I'm curious whether the same params boundary issue shows up once several layouts start sharing data.

React 19 Actions: I Explained 3 Hooks Without Ever Explaining What an Action Is

Shubhra Pokhariya — Tue, 01 Sep 2026 07:30:35 +0000

Three parts into this series, and if you'd asked me to define the word sitting underneath every single hook I'd taught you, I'm not sure I could have done it cleanly. That's not false modesty. Go back and read Parts 1 through 3. I used the word "Action" constantly. I never once stopped to say what one actually is.

Part 1 opened with three state variables I'd hand-rolled for years, a result, a pending flag, an error, and showed how useActionState collapses all three into one call. Part 2 took a comment box and made it feel instant before the server had even replied. Part 3 let a submit button three components away read a form's pending state with zero props passed down. Three different problems, three different hooks, and every single one of them was quietly leaning on the same mechanism without me ever naming it out loud.

That's the gap this post closes. Not a new bug this time. The concept the last three bugs were all symptoms of.

The word I kept using and never defined

Here's the actual definition, straight from React's own docs, not a paraphrase I'm softening for effect. A function called inside startTransition is an Action. That's it. That's the whole qualifying test.

async function submitFeedback(previousState, formData) {
  const message = formData.get("message");
  await saveFeedback(message);
  return { sent: true };
}

That function above could sit in your codebase forever and never once behave like an Action. What flips the switch has nothing to do with anything written inside it. It's entirely about the doorway it walks through. Four doorways do this: a direct startTransition call, useTransition's version of the same call, a form's action prop taking a function instead of a string, or useActionState. Walk a function through any of them and it stops being a plain async function you're tracking by hand. What React takes over automatically is the Transition itself, the pending tracking underneath it. What it does not universally hand you is the function's return value. useTransition gives you isPending and nothing else, a raw startTransition call doesn't return anything at all. useActionState is the one doorway built specifically to catch that return value and hold onto it as state, which is exactly why isPending and a real result showed up together back in Part 1 and nowhere else in this series. More on the ordering side of this once useTransition shows up properly below.

Once that clicked for me, Parts 1 through 3 stopped looking like three separate hooks and started looking like three different windows onto the same room. useFormStatus reads the pending status of the nearest parent form, and now you know why, that pending status only exists in the first place because something wrapped the submission in a Transition. useOptimistic is the odd one out. It isn't a door into becoming an Action at all. It's a setter you call from inside one that's already running. Call it outside a Transition and it just won't behave the way Part 2 showed you.

Why any of this needed inventing

Part 1's opening line still holds up: every form needed the same three pieces of state, wired by hand, every time. That pattern wasn't unique to forms either. A delete button, a follow toggle, a checkout step, all needed the identical scaffolding rebuilt from scratch. React 19 added the ability to use async functions inside transitions in the first place, which is the foundation everything else in this series stands on. What you build on that foundation, whether you get a tracked result back or just a pending flag, depends on which of the four doorways you actually walk through. useActionState is the one that goes furthest, catching the return value as state. The others give you less by design.

`<form action={fn}>`, and the three things nobody tells you change

Before Actions existed, a form's only real path to running code was onSubmit, and that path came with requirements you had to remember every time. Call preventDefault, manually construct FormData from the event target, manage loading and error state by hand.

function OldForm() {
  function handleSubmit(e) {
    e.preventDefault();
    const formData = new FormData(e.target);
    // run the request, manage loading and error state yourself
  }
  return <form onSubmit={handleSubmit}>{/* ... */}</form>;
}

Swap onSubmit for a function passed straight to action and the mental model shifts more than the syntax suggests. Nothing calls preventDefault, not because you forgot it, but because React already knows this is an Action before the form ever fires, so the browser's default full-page reload was never going to happen in the first place. The function also stops receiving an event. It receives FormData directly, already built from every named field on the page, which is one less step you used to write by hand every time. And the request method itself stops being something you configure at all. A function passed to action always submits as POST, whatever you write in a method attribute sitting right next to it. That last one is the exact fact Part 3 ran into from the useFormStatus side, back when method kept coming back 'post' no matter what I expected walking in. It was never reading an attribute. It was reading the Action underneath it.

onSubmit still earns its keep for one job specifically. Anything that has to stop a submission before it starts, checking two password fields match, belongs there. By the time code inside the Action itself runs, the submission has already begun, so nothing in there can be the thing that prevents it.

Sync Actions exist. They're just not interesting

An Action doesn't have to be async. A plain synchronous function handed to the same four doors still counts, React still manages its lifecycle, but the pending window is usually too short to build UI around.

function resetSearch(previousState, formData) {
  return { query: "" };
}

The instant await shows up inside that function, everything from Parts 1 through 3 becomes worth having. React 18 required startTransition's callback to be synchronous. React 19 dropped that restriction, and that single change is what let useActionState, <form action={fn}>, and useTransition all accept async functions directly instead of you managing the async boundary by hand.

Client Actions and Server Functions are not the same word twice

Everything in this series so far has been a client Action, code that runs in the browser whether or not it talks to a server underneath. That version works identically in any React 19 setup, no framework required.

Server Functions are a related but genuinely separate idea, and they only exist in frameworks with Server Component support, Next.js being the obvious one. React's own docs are specific about the relationship here, and it's worth getting right instead of using the two terms interchangeably like I nearly did drafting this: a Server Function only becomes a Server Action once it's passed to an action prop or called from inside an Action. Not every Server Function is a Server Action. Every Server Action used this way is a Server Function.

"use server";

export async function submitFeedback(formData) {
  const message = formData.get("message");
  await db.feedback.create({ message });
}

That single formData argument is the shape a Server Function receives when it's handed directly to a form's action prop. It's worth flagging because it's not interchangeable with useActionState as-is, which always calls its function with (previousState, formData), the two-argument shape Part 1 introduced. Reusing server logic through useActionState means writing for that shape from the start, not dropping in a single-argument version and hoping React adapts it for you. It won't.

The fourth door: useTransition

useTransition hasn't come up by name once in this series, and the mechanism it exposes has been running underneath every single example anyway. Calling it gives you exactly two things back, an isPending flag and a startTransition function.

Every checkout example so far ran inside a <form>, which wraps its Action in a Transition automatically. useTransition is for when there's no form to lean on. Picture a wishlist heart icon sitting on a product card, no form anywhere near it, just a click handler that needs to hit the server and report whether it's pending.

import { useTransition, useState } from "react";

function WishlistButton({ productId, isSaved, toggleWishlist }) {
  const [isPending, startTransition] = useTransition();
  const [saved, setSaved] = useState(isSaved);

  function handleClick() {
    startTransition(async () => {
      setSaved(!saved);
      const result = await toggleWishlist(productId);
      startTransition(() => {
        setSaved(result.saved);
      });
    });
  }

  return (
    <button onClick={handleClick} disabled={isPending} aria-pressed={saved}>
      {saved ? "♥ Saved" : "♡ Save"}
    </button>
  );
}

Notice that second, nested startTransition wrapping setSaved after the await. If that looks familiar, it should, it's the exact same shape as onConfirmed getting wrapped in its own startTransition back in Part 2's comment box. That's not two separate patterns you happened to see twice. React only automatically tracks synchronous work as part of a Transition. Anything after an await needs its own startTransition call to still count, whether you're inside a comment form or a heart icon with no form in sight.

Notice too that the wishlist button above reaches for plain useState, not useOptimistic. That's not an oversight. This example exists to isolate what useTransition gives you entirely on its own, before any of the other three hooks get involved. In a real app you'd almost certainly reach for useOptimistic here instead, the exact instant-feedback job it was built for back in Part 2. Showing it with bare useState first is the only way to actually see what useTransition alone is doing.

Here's the part that's easy to miss and expensive to find out the hard way. Click that heart, unclick it, click it again fast, and a raw useTransition call gives you no guarantee about which result lands last. React says so directly: Actions inside a Transition don't guarantee execution order on their own. What's easy to assume, and what I nearly wrote into this section before checking, is that <form action={fn}> is just as exposed to that same problem as a bare useTransition call. It isn't. React's own docs group <form> actions together with useActionState as the two built-in ways that already handle ordering for you. It's raw useTransition, used on its own with nothing else wrapping it, that gets no such guarantee, the wishlist button above included. If you've been assuming that guarantee comes from Actions in general, it doesn't. It's specifically what useActionState and <form> actions add on top of the raw mechanism.

Where the four actually sit next to each other

You need to...	Reach for
Own a form's result and pending state in one place	`useActionState`
Show the finished UI before the server has confirmed it	`useOptimistic`
Read a form's pending state from a component that isn't managing it	`useFormStatus`
Run an Action outside a form and track its pending state	`useTransition`

They were never four competing answers to "which hook should I learn." They're four answers to four different questions that happen to share one mechanism underneath. The checkout form from Part 3 already proved it by combining two of them across four separate components, useActionState owning the submission, useFormStatus letting PlaceOrderButton read pending state with nothing passed down. Here's that same order form with a third hook layered on, a promo code that discounts the total the moment the form is submitted with it, before the server has confirmed anything.

import { useActionState, useOptimistic } from "react";
import { useFormStatus } from "react-dom";

async function placeOrder(previousState, formData) {
  const result = await submitOrder(formData);
  return { orderId: result.id, error: null };
}

function PlaceOrderButton() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? "Placing order..." : "Place order"}
    </button>
  );
}

function OrderForm({ cartTotal }) {
  const [state, formAction] = useActionState(placeOrder, {
    orderId: null,
    error: null,
  });

  const [displayTotal, applyDiscount] = useOptimistic(
    cartTotal,
    (current, discount) => current - discount,
  );

  function handleSubmit(formData) {
    if (formData.get("promoCode") === "SAVE10") {
      applyDiscount(10);
    }
    formAction(formData);
  }

  return (
    <form action={handleSubmit}>
      <p>Total: ${displayTotal.toFixed(2)}</p>
      <input name="promoCode" placeholder="Promo code" />
      <PaymentFields />
      <PlaceOrderButton />
    </form>
  );
}

useActionState still owns the real submission the same way it did in Part 3. useOptimistic shows the discounted total the moment the form submits with SAVE10 in the field, no waiting on submitOrder to confirm anything first, and it falls back on its own to whatever cartTotal currently is once the Transition settles. That fallback detail matters more than it looks. This trimmed-down version never actually updates cartTotal after submitOrder resolves, so the discount would vanish the instant the Action finishes, same trap Part 2 walked through with onConfirmed. A real version needs the parent to fold the confirmed, discounted total back into cartTotal once the order actually goes through, or the optimistic value has nothing real to settle into. useFormStatus still lets PlaceOrderButton disable itself with nothing passed down from OrderForm. Three hooks, one form, none of them stepping on the other's job.

The mistake I nearly baked into this whole series

Here's the trap I think this series set without meaning to. Teach one hook per post, three posts in a row, and a careful reader could walk away thinking the real task was picking a favorite, useActionState or useOptimistic or useFormStatus, as if only one of them belongs in a given form. That was never true. Composition was always the point. A real form rarely reaches for exactly one of these. It reaches for whichever two or three actually solve the piece of the problem sitting in front of it, and none of them are competing for the same job.

I built this series backwards on purpose, honestly, three concrete bugs before the concept underneath them, because I think a concept sticks harder once you've already felt the shape of the problem it solves. But it only works if the concept actually shows up eventually. This is that part.

If you want the deeper cut, sync versus async Actions in more detail, the full Server Functions section, and a proper FAQ, I wrote the complete version on my site: React 19 Actions Explained.

If you'd rather test what actually stuck first, I also built a 15-question quiz covering the same four APIs: React 19 Actions Quiz.

So here's the real question, the one I'd genuinely like an answer to. Which of these four have you already been using without knowing you were touching an Action? A <form action={fn}> you wired up because it looked simpler than onSubmit, a startTransition call you copied from somewhere without reading what it does, a button that felt laggy until you wrapped it in useTransition and never asked why that fixed it. Drop it below. I'm curious how many of us have been using this mechanism for months without a name for it.

I Turned On Cache Components in Next.js 16.3. It Refused to Build My Simplest Page.

Shubhra Pokhariya — Wed, 19 Aug 2026 13:58:25 +0000

I didn't want to write another "what's new in Next.js 16.3" post. Enough of those exist. I wanted to know what actually happens when you flip the flags on a real project, so I scaffolded a fresh app, turned on cacheComponents and partialPrefetching, and tried to build the simplest possible dynamic page.

It didn't build.

The setup

Nothing fancy. Fresh create-next-app, Next.js 16.3.1, two flags in next.config.ts:

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

Then a product page. No database, no external API, not even a real fetch, just a fake delay and the route's own params:

async function getProduct(id: string) {
  await new Promise((resolve) => setTimeout(resolve, 300));
  return { id, name: `Product ${id}`, price: 42 };
}

export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id);

  return (
    <main className="p-8">
      <h1 className="text-2xl font-bold">{product.name}</h1>
      <p>${product.price}</p>
    </main>
  );
}

That's about as plain as a dynamic route gets. I expected next build to shrug and move on.

What actually happened

Error: Route "/products/[id]": Next.js encountered uncached or runtime data during prerendering.

`fetch(...)`, `cookies()`, `headers()`, `params`, `searchParams`, or `connection()` accessed outside of `<Suspense>` prevents the route from being prerendered, blocking the page load and leading to a slower user experience.

Ways to fix this:
  - [stream] Provide a placeholder with `<Suspense fallback={...}>` around the data access
  - [cache] For uncached data (`fetch`, database calls): cache the access with `"use cache"` (does not apply to `connection()`)
  - [block] Set `export const instant = false` to allow a blocking route

Full build failure. Exit code 1. For a page whose only "dynamic" behavior is reading a param that's obviously going to be there.

My first reaction was that this felt aggressive. My second reaction, after rereading it, was that this is the whole point of the release and I'd missed it by only skimming the changelog. Cache Components in 16.3 doesn't treat an unguarded dynamic access as a warning. It treats it as a decision you have to make, explicitly, before it'll ship your build. Stream it, cache it, or mark it blocking on purpose. No silent fourth option where it just works and you find out it was never instant three months from now.

The fix, and what it actually buys you

I took the option the error suggested first: wrap the part that awaits params in <Suspense>.

import { Suspense } from "react";

async function getProduct(id: string) {
  await new Promise((resolve) => setTimeout(resolve, 300));
  return { id, name: `Product ${id}`, price: 42 };
}

async function ProductDetails({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const product = await getProduct(id);
  return (
    <>
      <h1 className="text-2xl font-bold">{product.name}</h1>
      <p>${product.price}</p>
    </>
  );
}

export default function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  return (
    <main className="p-8">
      <Suspense fallback={<p>Loading product...</p>}>
        <ProductDetails params={params} />
      </Suspense>
    </main>
  );
}

Ran the build again:

Route (app)
┌ ○ /
├ ○ /_not-found
└   /products/[id]
  └ ◐ /products/[id]

○  (Static)             prerendered as static content
◐  (Partial Prerender)  prerendered as static HTML with dynamic server-streamed content

That ◐ next to my product route is the actual feature. Next.js pulled out everything around the Suspense boundary, the shell, and prerendered it. The part that actually depends on which product you clicked streams in behind it. That's Cache Components' Partial Prerendering doing exactly what it's supposed to, a real route in a real build output, not a description from the release notes. It's also the same shell mechanism that Partial Prefetching, the client-side navigation feature 16.3 adds on top of this, depends on existing in the first place.

What this told me that the changelog didn't

Reading about Partial Prefetching, "a reusable shell per route, cached on the client," sounds like a nice-to-have you'd adopt when you get around to it. Hitting the build error told me something different: on a 16.3 app with Cache Components on, there's no version of "get around to it." Every uncached or runtime access Next.js finds during prerendering needs an answer, stream, cache, or block, the moment you turn the flag on. It's not gradual. It's a build gate.

That's a bigger adoption cost than "add two lines to your config" makes it sound, and I think that's exactly why Next.js ships next-cache-components-adoption as a first-party agent Skill now instead of leaving you to hunt down every unguarded params and cookies() call by hand across a real app. On a five-file test project this took me two minutes. On a real production route tree, I wouldn't want to do it without that tool, or without a very good sense of where every Suspense boundary in the app already is.

Where I'd actually start

If you're evaluating this for a real app: don't turn the flag on for the whole project and see what catches fire. Pick one route, ideally your simplest dynamic one, and watch what the build tells you it needs. It will tell you exactly what to do next. That part, at least, the error message gets right.

I wrote a longer breakdown of the full 16.3 release, what upgrades automatically with zero config changes, what Instant Navigations and Partial Prefetching actually change, and what shipped for AI agents, on my website if you want the whole picture before you decide whether to flip these flags on something real.

Has anyone else run the migration on an actual production route tree yet? I'd like to know what the first pass looks like on a real app.

React 19's useFormStatus Fixed My Prop Drilling. Then It Sat There Returning False

Shubhra Pokhariya — Wed, 12 Aug 2026 12:04:31 +0000

Part 1 was about waiting well. Part 2 was about not waiting at all. This one is about a value I needed in a component that never created it, and about the ten minutes I lost putting the hook in the one place it can't work.

If you've read Part 1 on useActionState and Part 2 on useOptimistic, both of those hooks answer a question from inside the component that called them. That was never a problem for a two-field newsletter form. It became one the day I split an order form into separate pieces, payment details in one file, the place-order button in another, and both of them needed to know the same thing: is this thing submitting right now.

The setup that made prop drilling look reasonable

Here's roughly what the form looked like before I touched useFormStatus at all.

import { useActionState } from "react";

function PaymentFields({ disabled }) {
  return (
    <fieldset disabled={disabled}>
      <input name="cardNumber" placeholder="Card number" />
      <input name="cardExpiry" placeholder="MM/YY" />
    </fieldset>
  );
}

function PlaceOrderButton({ pending }) {
  return (
    <button type="submit" disabled={pending}>
      {pending ? "Placing order..." : "Place order"}
    </button>
  );
}

function OrderForm() {
  const [state, formAction, isPending] = useActionState(placeOrder, {
    message: "",
  });

  return (
    <form action={formAction}>
      <PaymentFields disabled={isPending} />
      <PlaceOrderButton pending={isPending} />
    </form>
  );
}

Nothing about this is broken. It works. But isPending lives in OrderForm, and both children only exist to receive it and hand it to a disabled attribute. Add a shipping section, an order-summary sidebar, a coupon field that should lock during submission, and every one of them needs the same prop threaded through, whether or not anything else about them changes. I'd read that useFormStatus was built to skip exactly this, so I went looking for where to put it.

Where I put it first, and why it did nothing

My first instinct was to call the hook right where isPending used to live, in OrderForm itself, treating it like a drop-in replacement.

import { useFormStatus } from "react-dom";

function OrderForm() {
  const { pending } = useFormStatus(); // stays false forever

  return (
    <form action={placeOrder}>
      <PaymentFields disabled={pending} />
      <PlaceOrderButton pending={pending} />
    </form>
  );
}

I clicked "Place order." Nothing disabled. No console warning, no red error overlay, just a button sitting there fully clickable while the network tab showed a request in flight. My first guess was that placeOrder wasn't actually async, or that I'd broken something in the action itself. I spent a few minutes staring at the action function before I even looked back at the hook.

The actual answer is simpler and, once you see it, a little obvious. useFormStatus doesn't read state that OrderForm owns. It reads the status of the parent <form>, and at the moment that hook call runs, OrderForm is still deciding what to render. The <form> tag doesn't exist as anyone's parent yet, it's the thing being built. There's no ancestor for the hook to find, so it falls back to its default, unpending shape, and it stays that way no matter how long the real submission takes.

The rule underneath that: the component calling useFormStatus has to be a descendant of the form it wants to read, never the component rendering the form itself. Fixing it meant pulling the hook out of OrderForm and putting it somewhere further down the tree.

import { useFormStatus } from "react-dom";

function PaymentFields() {
  const { pending } = useFormStatus();
  return (
    <fieldset disabled={pending}>
      <input name="cardNumber" placeholder="Card number" />
      <input name="cardExpiry" placeholder="MM/YY" />
    </fieldset>
  );
}

function PlaceOrderButton() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? "Placing order..." : "Place order"}
    </button>
  );
}

function OrderForm() {
  return (
    <form action={placeOrder}>
      <PaymentFields />
      <PlaceOrderButton />
    </form>
  );
}

Same markup, same behavior at a glance, and suddenly pending flips correctly. Neither child receives anything from OrderForm anymore. Both just ask their parent form what's going on and get told the truth.

One detail that's easy to miss on the way there: this hook comes from react-dom, not react. useActionState and useOptimistic both live in react, so if you're moving through this series in order, typing import { useFormStatus } from "react" is a genuinely easy slip, and it fails in a way that doesn't tell you what went wrong either.

The part I didn't expect: it's watching more than a boolean

Once pending worked, I assumed that was the whole hook. It isn't. Calling it gives you an object with three more properties riding along, and I only found a real use for them once I stopped treating useFormStatus as a fancy boolean.

const { pending, data, method, action } = useFormStatus();

data is the FormData currently being submitted, available only while something is in flight. I used it to make the button say something more specific than a generic spinner label:

function PlaceOrderButton() {
  const { pending, data } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? `Placing order for ${data.get("email")}...` : "Place order"}
    </button>
  );
}

data is null the rest of the time, so that .get("email") call only runs safely because it's tucked inside the pending branch of the ternary. Pull it out and call it unconditionally, and the component throws the first time it renders idle.

method is where I got tripped up briefly, because I assumed it would mirror whatever method attribute I'd have put on the form. It doesn't work that way once you're using a function-based action. Any form using the action prop with a function, which is the entire reason this hook has something to track in the first place, submits as 'post' regardless of anything else you configure. You'd only see 'get' here on a form using a plain URL string as its action, or no action prop at all, and the docs only commit to one thing about that case: action itself comes back null. They stay quiet on pending and data, and since only function-based actions actually run through React's Transition tracking, that's not a combination I'd build anything around.

action is a reference back to whatever function you passed to the form's action prop. It's null for a form with no function-based action, and it's also null if there's no parent form at all, which means a falsy value here doesn't automatically tell you which of those two is true. I hit this once trying to conditionally render something based on whether action existed, and had to remind myself both cases collapse to the same falsy check.

The reused-component trick I didn't plan for, and the one I got burned by

The nicest surprise came later, almost by accident. PlaceOrderButton wasn't just used on the checkout page. It got reused, unmodified, on a "save draft order" form elsewhere in the app. I expected to need some kind of context or ID to tell it which form it belonged to. I didn't. useFormStatus resolves the nearest ancestor form independently everywhere it's rendered, so the same component read the correct pending state on both forms without a single line of extra wiring. That's not an edge case worth working around, it's a real reason to build small, reusable status-aware components in the first place.

The edge case that did surprise me went the other direction. Somewhere in an admin panel, a designer had wired a button outside its form using the HTML form="orderForm" attribute instead of physically nesting it. Pure HTML, no React opinion needed, and it submits the form fine. useFormStatus inside that button read as permanently not-pending, even while the form it was technically attached to was mid-submission. The hook walks the component tree, not the DOM-level form attribute association, so as far as it's concerned, that button was never a child of anything. Worth knowing before it surprises you in a codebase that uses this attribute anywhere.

Where I stopped reaching for it

Not every form needed this. On a two-field signup form with a single button in the same component, useActionState's own isPending, read directly where the hook was called, did the job without adding a second hook and a second rule to remember. useFormStatus earns its place once a form's parts genuinely live in separate components, not before.

And it only ever tells you about a submission already underway. useFormStatus isn't a validation API, it tells you what the form is doing once submission has started, not whether that submission should have been allowed to start in the first place. That decision still belongs upstream, in the action function or wherever else you're handling the submit.

Where useActionState, useOptimistic, and useFormStatus actually sit

Three parts into this series and the boundaries finally made sense to me as one picture instead of three separate hooks to memorize. useActionState owns a result and reacts to it, from wherever it was called. useOptimistic shows the finished UI before the server has actually agreed to it. useFormStatus answers one question, is this form pending, from any component underneath it, with nothing passed down to make that possible.

The distinction that finally made it stick for me: useActionState's isPending follows an Action, specifically the one dispatched through that hook call. useFormStatus's pending follows a form, whichever <form> happens to be its nearest parent, regardless of which component or which action put it there. That's why the same PlaceOrderButton worked unmodified on two different forms with two different actions later on. It was never watching an action. It was watching whatever form it happened to be sitting inside.

They stack without fighting each other. The order form I started with ended up using two of the three, useActionState in the parent owning the result, useFormStatus in every child section reading the same pending state independently.

I wrote the full breakdown on my site, including the complete four-section checkout example combining both hooks, the exact difference between this and useActionState's own isPending, and a side-by-side table for picking the right one: React 19 useFormStatus Explained.

If you want to test what you just learned, I also put together a short React 19 useFormStatus Quiz.

If you've built a form where the submit button lives three components away from the one managing the submission, it's worth checking where you actually called the hook before you assume something's broken. I know that's exactly where I lost ten minutes I didn't need to.