Coder Legion - Recent posts tagged prisma

Cancel or send: one winner. An order flow on Prisma Postgres and Compute

Wed, 28 Oct 2026 21:30:34 +0000

Werbung / Disclosure: Prisma gave me a coupon for two months of a paid plan for free and said it will add free credits, so I could try Prisma Postgres and Compute for this project. All results below come from my own runs.

Summary

I built an order flow with a 10-minute grace period. Cancellation and dispatch must have exactly one winner in the database.
The winner is decided in Postgres, with a guarded update, a row lock and SKIP LOCKED. No clock and no timer decides it.
I broke the code on purpose, one line at a time, to check that my tests really fail. One of my race tests passed even without the lock.
On Compute, an idle app sleeps. My poller is a timer inside the server, so it only runs when someone calls the app. This changes the timing, not the correctness.

The problem

A customer orders a custom T-shirt. I promise a grace period of 10 minutes. During that time the customer can cancel. After that, the printer gets an email and the customer cannot cancel any more.

Two things can happen at almost the same moment. The customer presses cancel, and my poller wants to send. Exactly one of them must win. A cancelled order must never reach the printer, because an email cannot be recalled.

Design decisions

Claim first, then send

The poller claims an order by changing its status from PENDING to SENT before it sends the email. If the customer cancels first, the claim finds nothing. If the claim wins, the cancel is rejected with a 409.

Here, SENT means the order has been claimed for dispatch, not that the email has been delivered. If the server crashes after the claim, the printer may get no email. I set printerNotifiedAt only after Resend accepts it. A stuck-order query finds SENT orders without that timestamp, and a resend route lets me recover them.Sending the email before claiming the order could allow it to be sent even if the cancellation wins the database race.

A guarded transition

Every status change goes through one function. It checks that the transition is allowed for the actor. Then it writes with the old status in the where clause:

const { count } = await prisma.order.updateMany({
  where: { id, status: order.status },
  data: { status: to },
});
if (count === 0) throw new ConflictException('Order changed, please retry');

If someone changed the row between my read and my write, count is 0 and the caller gets a 409. This is the sixth time I used this read-then-write pattern across my projects.

A Postgres poller, not a queue

The hosted version has no Redis, so there is no BullMQ. The order and its deadline are written in one transaction. A timer loop claims due orders with one statement:

UPDATE "Order" SET status = 'SENT' -- plus updatedAt
WHERE id IN (
  SELECT id FROM "Order"
  WHERE status = 'PENDING' AND "sendAt" <= (now() AT TIME ZONE 'UTC')
  ORDER BY "sendAt" LIMIT 10
  FOR UPDATE SKIP LOCKED
)
RETURNING id

There is no enqueue gap, because the deadline is data. The costs are a polling delay and retry logic that I write myself. Today there is no automatic retry. The safety net is the stuck-order query and the resend route.

The server owns sendAt. A client-supplied value could skip the grace period, so the request schema rejects unknown keys.

A row lock on the design

An order points at a design. If the design changes after the order exists, the printer prints something the customer never ordered, and nobody sees an error. Creating an order, updating a design and deleting a design all take SELECT ... FOR UPDATE on the design row first. A design counts as locked when it has any order that is not cancelled.

Tests, and a test that proved nothing

I wrote integration tests against a real Postgres database. Then I broke the code on purpose, one line at a time, and checked that a test turned red.

I removed	What went red
the status in the `updateMany` guard	the cancel-versus-poller test, and all 30 printer/admin confirm iterations
`status = 'PENDING'` in the claim	a cancelled order was emailed, and two pollers sent two emails
`SKIP LOCKED`	the locked-row test (the pollers waited)
`FOR UPDATE` in order creation	only the deterministic lock test
`FOR UPDATE` in design update	only the deterministic lock test (65 passed, 1 failed)
`FOR UPDATE` in design removal	the remove-versus-create test: a foreign key error instead of a 409

The lock rows are the lesson. First I tested the lock with 30 free-running iterations of update versus create. They all passed with the lock removed. The broken interleaving ends in the same final database state as the harmless one, so no assertion on the final state can tell them apart. Only a test that pauses order creation after it takes the lock, and then checks whether the update can finish, sees the bug.

A test also found a timezone bug. I ran the integration session in America/Los_Angeles. Comparing sendAt with a bare now() failed because sendAt is a timestamp without time zone. The comparison now uses now() AT TIME ZONE 'UTC', assuming sendAt is stored as a UTC timestamp. This fixes the timezone interpretation, but not clock skew between the application and database; I discuss that remaining limitation below.

Prisma Postgres and Compute

Prisma ORM 8 (I write Prisma 8 for short) is a release candidate and Composer is in Early Access. Compute has been generally available since August 2026. Everything in this section was true on my machine in October 2026. Versions: Prisma CLI 8.0.0-rc.27, @prisma/orm-postgres 8.0.0-rc.20, Composer 0.34.0.

Why Prisma ORM 8 is in this project

The Console told me that my repository used prisma ^7.7.0, that deploys run on Prisma 8, and that I should upgrade first. So I installed Prisma 8 next to Prisma 7, inferred a contract from my database, and planned a baseline migration. The plan had 15 operations from an empty database: four enums, four tables, the (status, sendAt) index and four foreign keys.

Later, Martin from Prisma told me that a Prisma 7 app runs fine on Compute and that Prisma 8 is not required. I did not test a Prisma 7 only deploy myself, so I cannot confirm it, and I reported the Console banner to Prisma.

I kept Prisma 8 for one job: the deploy applies my baseline migration to the new database. My queries still run on Prisma 7 with the pg adapter. The docs also describe a plainer option, rawPostgres(), which hands your own client a db.url. With it, you migrate the database yourself. I did not use it.

I kept the queries on Prisma 7 for another reason. The release status page lists what Prisma 8 does not have yet, for example transaction isolation levels, atomic increment, most nested writes and P2002-style error codes. My locks use raw SQL and a guarded updateMany, and I did not try them on Prisma 8.

Two more facts for Prisma 7 users. First, npx prisma now runs the Prisma 8 CLI, which has different data commands (contract, db and migration). Pin prisma to ^7 and use npx prisma@7, or install an alias package like I did. Second, Prisma 8 is a release candidate, and the release status page expects general availability in October 2026.

Getting a NestJS 11 app onto Compute

Compute runs a single bundled file. My notes:

The deploy tool refused Node 22.23.4 and asked for Node 24.11.1 or newer. The Compute docs say Node 22.18 or newer on the 22 line is enough, so the docs and the tool disagree.
bcrypt is a native addon. Bundled into one file, it crashed at startup with __dirname is not defined. I switched to bcryptjs. Login and the tests still passed.
prisma dev is not supported on Windows yet, so I tested the bundle with plain node.
Composer needs type: module. I put the Composer files in a deploy folder with its own package.json, so nest build stays CommonJS. A small launcher reads the database URL that the platform provides and then starts the compiled app.
The Console's setup pull request failed at npm install with ERESOLVE. I could reproduce a conflict on my machine by adding alchemy next to Jest 30 (a Babel peer dependency clash). I could not see the Console's log, so I do not know if it is the same cause.

The first deploy created ten resources, including the database and the migration step, and returned a public URL. The docs say Compute runs deployed apps on Bun, and I built my bundle for Node. The app worked when I tried it. The poller is switched off on that deployment, so orders stay PENDING there.

The surprise: scale to zero versus my poller

My poller is a timer inside the server. I deployed a small test app with a counter that ticks every 5 seconds and shows its history. Then I left it alone overnight.

The startedAt value was the same after 15 hours, so the app was never restarted.
Only 2 ticks were recorded. The first gap was 54,940 seconds.
New ticks appeared at the moments I opened the page. Then they stopped again.

The Compute docs describe this: idle instances sleep with a memory snapshot and resume in milliseconds. A timer inside the process only runs when someone calls the app.

What still holds: one database claim wins, and a cancelled order cannot be claimed for dispatch through this flow. What breaks is the timing. The email goes out after the next request, not at minute 10. Exactly-once email delivery is not guaranteed; a crash during recovery can result in a duplicate.

Open question: where should the poller run?

Compute has no built-in cron scheduler. A Prisma engineer told me that the recommended patterns are options 2 and 3 below, and that keep-awake is meant for short, bounded work. The Compute limitations page and the Composer cron building block describe both. I have not chosen between them yet, and I would like to discuss it. These are the options I found:

Keep the instance awake. Prisma says keep-awake is meant for short, bounded work, not for an always-on loop. The docs add that it does not guarantee continuity through restarts or deployments. I have not measured what a permanently awake instance costs.
An external trigger (recommended by Prisma). A scheduler outside Compute calls a protected route. The route wakes the app, runs the same claim logic and returns. My tests show that extra triggers are safe: two pollers claim an order once. The timing precision depends on the scheduler, and the request must start responding within 60 seconds.
The Composer cron building block (recommended by Prisma). Its scheduler is a service that never scales to zero, so it costs one warm instance. Composer is in Early Access, and I did not find an example of mounting the cron runner in a NestJS app.

Questions that are still open:

Does the always-warm cron scheduler count against the Free plan, and how much memory does it use?
Has anyone mounted the cron runner inside a NestJS app?

If you solved this, I would like to hear how.

Raw output

These are trimmed outputs from my own runs.

The deploy:

t-shirt-backend-test
├─ database   postgres-database db_...
└─ app        compute-service cps_...
Stack deployed (10/10)
Deployed t-shirt-backend-test to production in 3m 1s.

The bundle with the native bcrypt addon, at startup:

ReferenceError: __dirname is not defined in ES module scope
    at ... require_node_gyp_build()(path.resolve(__dirname))

The test app's ticks, first call (15 hours after the deploy):

{"startedAt":"2026-10-25T16:36:23.113Z","now":"2026-10-26T07:59:53.581Z","count":2,
 "gaps":[{"from":"2026-10-25T16:42:26.838Z","to":"2026-10-26T07:58:06.462Z","seconds":54940}]}

The second call, about 10 minutes later (the first gap is shortened):

{"startedAt":"2026-10-25T16:36:23.113Z","now":"2026-10-26T08:10:05.860Z","count":4,
 "gaps":[{"seconds":54940},{"from":"2026-10-26T07:58:06.462Z","to":"2026-10-26T07:59:53.591Z","seconds":107}]}

Two failures from the mutation runs:

status guard removed, confirm race:   Expected length: 1   Received length: 2
design lock removed, lock-held test:  Expected: "rejected"  Received: "fulfilled"

What I did not verify

I did not run the poller on Compute under load, and I did not measure how late the emails are.
I have not fixed clock skew between the app server and the database. sendAt is written from the app clock and compared with the database clock, so skew changes the grace period silently.
There is no automatic retry for failed emails.
I did not port locks and transactions to Prisma 8. They stay on Prisma 7.

Takeaways

Let the database decide the winner. Do not let a timer or a clock decide it.
Break your code on purpose. A test that also passes without the guard proves nothing.
A free-running race loop can pass for the wrong reason. Force the interleaving.
Scale to zero changes what a timer inside your server means. Check it before you design around it.

I'm Mhamd, a backend engineer working with NestJS and TypeScript. Portfolio: mhamd021.github.io · GitHub: Mhamd021

The Reconnect Bug Where Marking a User Online Erased the Data I Needed for Replay

Thu, 15 Oct 2026 07:00:41 +0000

While testing a reconnect system for a deliverer-facing WebSocket gateway: when someone reconnects after losing their connection, they should get a snapshot of their current job plus any events they missed while offline. Two pieces, both of which I was confident were correct on their own.

Marking presence:

async markOnline(userId: number) {
  await this.prisma.user.update({
    where: { id: userId },
    data: { isOnline: true, lastSeenAt: new Date() },
  });
}

Computing what was missed:

async replayDelivererEvents(delivererId: number) {
  const deliverer = await this.prisma.delivererProfile.findUnique({
    where: { id: delivererId },
    select: { user: { select: { lastSeenAt: true } }, activeJobId: true },
  });
  // ...fetch events since deliverer.user.lastSeenAt
}

And the connection handler that used both:

async handleConnection(client: Socket) {
  const deliverer = await this.getDelivererByUserId(payload.sub);

  await this.sessionService.markOnline(payload.sub);           // step 1
  const missedEvents = await this.replayService.replayForDeliverer(deliverer.id); // step 2

  client.emit('events.replay', missedEvents);
}

I tested it: disconnect, trigger a job assignment while offline, reconnect. events.replay came back empty, every time. The event genuinely happened. The query genuinely should have found it.

Why

Walk through the actual timeline. A deliverer disconnects — markOffline correctly stamps lastSeenAt with the disconnect time. Later, they reconnect. handleConnection fires, and the first thing it does is call markOnline, which immediately overwrites lastSeenAt to right now. Only after that does it call replayForDeliverer, which reads lastSeenAt to compute "what happened since they were last seen" except by then lastSeenAt no longer holds the disconnect time. It holds the current moment, because the line above just wrote over it.

getEventsSince({ since: lastSeenAt }) effectively became since: right now. The replay feature couldn't fail more quietly — no error, no exception, just a correctly-shaped empty array every single time.

What makes this bug worth writing about isn't the fix — it's that neither piece of code was wrong in isolation. Marking someone online should update lastSeenAt. Replay should read lastSeenAt. The bug only exists in the order they ran in, and that kind of bug doesn't show up by staring at either function — only by tracing the actual sequence of operations across the whole request.

The fix
Read before you overwrite:

async handleConnection(client: Socket) {
  const deliverer = await this.getDelivererByUserId(payload.sub);

  // Replay FIRST, using the lastSeenAt from before this connection
  const missedEvents = await this.replayService.replayForDeliverer(deliverer.id);

  // THEN mark online, which overwrites lastSeenAt for next time
  await this.sessionService.markOnline(payload.sub);

  client.emit('events.replay', missedEvents);
}

No schema change needed. Reordering two already-correct operations was the entire fix.

The part worth remembering

One field, two different jobs — "when did we last hear a heartbeat" and "what's the anchor point for replay" happened to share the same column, and that's exactly what made the collision possible. The one-line reorder fixes today's bug, but it leaves the deeper coupling in place: anything else that later wants to read lastSeenAt for a different purpose can walk into the same trap. The more robust version splits them. a dedicated lastDisconnectedAt, set only on disconnect, read only by replay so two unrelated concerns stop sharing state that one of them mutates as a side effect. I haven't built that yet. It's on the list specifically because I know why it would help, not just that it might.

Calling a Service Inside prisma.$transaction Doesn't Make It Atomic — Here's the Bug That Taught Me

Mon, 12 Oct 2026 09:22:43 +0000

I was fixing a real bug in a delivery backend I'm building: a customer's order could get created in Postgres even when something downstream failed, leaving an order with no event history behind it. The fix looked simple. Wrap the whole thing in
prisma.$transaction:

const order = await this.prisma.$transaction(async (tx) => {
  const newOrder = await tx.order.create({ data: { ... } });

  await this.eventLogService.recordEvent({
    entityType: 'ORDER',
    entityId: newOrder.id,
    eventType: EVENTS.ORDER.CREATED,
    payload: { orderId: newOrder.id, status: OrderStatus.PENDING_VENDOR_CONFIRMATION },
  });

  return newOrder;
});

I ran it, broke the event-logging step on purpose to test the rollback, and the order still got committed. The transaction did nothing.

Why

$transaction(async (tx) => {...}) opens one database connection and starts a transaction on it. The tx object you get inside the callback is bound to that specific connection. Every query run through tx participates in the same transaction.

My EventLogService.recordEvent method didn't use tx. It used this.prisma — its own injected Prisma client, a completely different connection:

async recordEvent(params) {
  const event = await this.prisma.eventLog.create({ ... }); // not tx — its own connection
  ...
}

Nesting the call inside $transaction changes nothing here. Prisma has no way to know "we're inside a transaction right now, please route all queries through it." The only thing that determines whether a query participates in a transaction is which client object actually executed it. Since recordEvent ran on its own connection, its insert committed instantly and independently, with no awareness that anything else was "inside" a transaction around it.

The fix
Every method that needs to be transaction-capable has to accept an optional transaction client and fall back to the default when none is passed:

async recordEvent(params, tx?: Prisma.TransactionClient) {
  const client = tx ?? this.prisma;
  const event = await client.eventLog.create({ data: params });
  ...
}

Then the caller passes its own tx through explicitly:

await this.eventLogService.recordEvent(params, tx);

Now recordEvent's insert runs on the same connection, inside the same transaction, as everything else. If anything later in that transaction throws, Postgres rolls back the whole connection's uncommitted work — including this insert — because it genuinely was part of the same unit of work, not just nested inside it syntactically.

I retested the same failure scenario. This time, the order didn't get created either. Rollback worked as a single unit, order and event together.

The part worth remembering
Code structure and transaction membership are two different things. A function call being lexically inside a $transaction block tells you nothing about which database connection it actually used. If you're composing transactional logic across services in Prisma — or any ORM with a similar explicit-client model — every service in that chain needs to accept and thread through the transaction client deliberately. There's no implicit "ambient transaction" you can rely on.

The honest cost: this makes service signatures a bit noisier — an extra optional parameter on every method that might need to participate in a caller's transaction. I think that's a fair trade for not silently losing atomicity on exactly the kind of multi-step write where you'd assume you had it.

How I Survived My First Full stack App with Next.js

Fri, 18 Jul 2025 12:38:28 +0000

The story begins—as it always does—with a tutorial.

I was watching yet another video and thought: “Let’s build a full stack app.” I already had a background in React, and I’d made a few full stack projects before. So this time, I chose Next.js. It looked easy, especially with the new App Router.

Why Next.js? Because it’s React at the front, backend APIs included, and server actions baked right in. No need for separate Express servers or wiring up extra routers. Also, the assumption was simple: everything is a server component unless you slap a "use client" on top. I was in.

✨ Why I Fell in Love with the App Router

One of the best things about Next.js is the App Router. You don’t need to install React Router and define routes in App.jsx. Just drop a file in the /app folder, and boom—it’s a route. It's simple. It’s fast. It works.

First Battle: The UI Fear

Here’s my harsh truth—I suck at design.

My pages looked ugly. And that really messes with you. It triggers imposter syndrome. I’d open VS Code, freeze, and think: What do I even build here? The spiral begins: “Am I even cut out for frontend dev?”

Sound familiar? Been there. This time, I didn’t let it win.

Here's how I beat the block:

Took breaks when stuck.
Drew wireframes, even if they were ugly. Just enough to give me direction.
Used inspiration from other websites. Seriously, 90% of the internet uses the same layout tricks. Why not learn from them?
Tools like Google Stitch, v0.dev, and Bolt helped generate page ideas and inspiration.

Any progress is better than no progress. Remember that.

❤️ Server Actions

God bless Server Actions.

No more creating an API route or writing fetch calls and handling them manually. Need to read from the server? Just keep the page component as a server component, use a Server Action to grab the data, and pass it down to your client components. Done.

You can use server actions inside client components too, but there are caveats. I won’t pretend I know them all—this project was me figuring things out on the fly. So I won’t preach, but here’s what worked for me:

Keep data fetching in server components.
Use server actions to mutate or fetch data.
If using forms, yes—you can still call server actions from client components.

How I Wrote Ugly Code—Fast

Not gonna lie. I was a messy developer in the beginning.

Every time I made a new page/component, I didn't care about reusability. Things got chaotic fast.

But I followed one rule: put every component inside a well-named folder. For example: /components/dashboard/Table.tsx. Later, when I needed it somewhere else, I refactored it—added props, defined interfaces, added type safety—and made it reusable.

So... am I a great React developer? Maybe not.

Am I resourceful and fast? Yes.

Best case: smart developer.

Worst case: functional chaos.

The Email Saga

Now I understand why dev’s complain about bad DX (Developer Experience) on Twitter.

Until now, I had a chill life—React + Vite, everything worked like magic. But for this project, I needed to send emails inviting users to give feedback.

I initially tried Mailjet — looked promising, solid docs, decent limits. But then... everything broke after sending just 5 emails.

I got hit with a "temporary restriction" and no real explanation. Just a vague message and complete silence. I waited three days, hoping the ban would lift. Spoiler: it didn’t.

That’s when I realized how important good developer experience really is.

If I ever build a dev tool, I’m writing great docs, clear errors, and probably a fun YouTube guide.

So, I ditched Mailjet and moved to Resend — and this time, everything just worked. Fast setup, friendly DX, and no cryptic errors.

❤️ Huge shoutout to Resend.

???? No hard feelings, Mailjet — but that experience wasn’t it.

The Broken Database Horror

After surviving all that, I wanted to brag on LinkedIn: “Hey look! I integrated payments!” Even if they were test payments—still, it’s progress.

But the horror unfolded quickly.

Understanding how payments work end-to-end—from initiation to confirmation—is critical. If you don’t, you’ll keep breaking your schema with every little change.

What I learned:

If you're dealing with third-party APIs or external systems, always:

Track their status (pending, success, failure)
Use enum fields to reflect the state
Expect that some parts of the flow are out of your control

Know what you're storing and when. Or prepare to suffer. And yes, it will become a dev horror story.

Linting + TypeScript Woes

I used to think linting was just that one VS Code extension that makes code pretty.

Then I ran npm run build.

Boom. 10,000+ lines of errors. Why? It tried to lint the auto-generated code too.

So yeah, I had to:

Fix unused variables
Replace any types
Update configs to ignore generated folders

Lesson learned: don't skip linting. TypeScript isn’t just for safety—it’s a build-saver.

Deployment & Production Nightmares

I’d spent a month building this project. Now it was time to ship. Resume-ready, you know?

I used Vercel. Guess what?

Vercel kept trying to render server pages as static. My build kept failing.

Turns out: Vercel will try to statically generate everything unless you tell it not to.

Solution:

export const dynamic = "force-dynamic";

Boom. Now it knows your page is meant to run server-side only.

Oh, and Supabase—my free DB. Connecting it was hell.

There’s a pooled connection (for normal ops)
And a direct connection (for migrations)

But Prisma didn’t play well with pooled URLs. It caused weird, unexpected issues.

Fix:

Use Supabase’s "stable connection string" for local + migrations
Use Prisma Accelerate in production with the correct URL
Add the Accelerate URL to your .env.production

After that, things worked. Kinda.

Final Thoughts

You may not have learned any technical tricks from this post. But that’s the point.

Things will break.

Abstractions will leak.

You’ll be stuck. Frustrated. Confused.

But you’re a builder. And builders show up.

That’s what matters.

❤️ Takeaway

Everyone can teach you code. I want to teach you a mindset.

If you remember just two things from this post:

Break things. That’s how you learn.
Draw wireframes. Ugly ones. It gives you momentum.

That’s it. You’ll be 10x faster than me if you just start.

Follow My Journey

I write about my dev rants, lessons, and experiments—sometimes messy, sometimes insightful. If this resonated, follow me. I don’t just rant—I teach too.

Next up: how I broke and optimized my backend.

Till then,

Break. Fix. Weep. Shine.

— Love and peace,

Your fellow dev

Farewell & Little Sendoff Gifts for Curious Minds

Thanks for sticking around! If you're curious to poke around or steal some ideas (I won't tell), here are a few goodies:

Live App:

Create Next App

GitHub Repo: https://github.com/PRASHANTSWAROOP001/feedback-nextjs-app
Wireframes (Chaos Included): https://raw.githubusercontent.com/PRASHANTSWAROOP001/contact-page/refs/heads/main/wireframe2.jpg, https://github.com/PRASHANTSWAROOP001/contact-page/blob/main/wireframe1.jpg?raw=true