The latest() Bug That Silently Duplicated Transaction IDs in Production

Ahmad Fauzan Alghifari — Mon, 20 Apr 2026 02:05:56 +0000

TL;DR: Using Model::latest()->first() to get the "latest" record by ID is wrong. latest() orders by created_at, not by the value of your ID column. When two rows are inserted within the same second, both reads return the same record, and you get duplicate IDs.

Background

I built a simple sequential ID generator for transaction IDs. The logic was straightforward: fetch the latest record, read its code, increment the number, return the next one.

$start = "XX00000001";
$latest = Model::latest()->first();

if (!$latest || !$latest->code) {
    return $start;
}

$value = $latest->code;

if (!preg_match('/^XX\d{8}$/', $value)) {
    return $start;
}

$num = (int) substr($value, -8);
return "XX" . str_pad($num + 1, 8, "0", STR_PAD_LEFT);

It worked. Passed local and dev branch testing. Got merged into production with no issues. Then one day, a user reported duplicate IDs on different transactions.

So What Happened?

My assumption was that latest() would always return the record with the highest ID. Logically, the latest record should have the highest code, right?

Wrong. latest() in Laravel is just a shorthand for orderBy('created_at', 'desc'). It doesn't care about your ID column, it orders by created_at.

This means the correctness of the whole function depends entirely on created_at being precise enough to differentiate between records. And it wasn't.

The created_at column was storing timestamps in DD:MM:YY hh:mm:ss format. The smallest unit is seconds. If two rows are inserted within the same second — whether by two users simultaneously, or by a backend loop calling this function in rapid succession, both calls to latest()->first() return the same record. Both read the same code. Both return the same next ID.

created_at	ID generated	note
20:04:01	XX00000001
20:04:01	XX00000002
20:04:01	XX00000002	DUPLICATE
20:04:01	XX00000002	DUPLICATE
20:04:02	XX00000003
20:04:02	XX00000003	DUPLICATE

The bug wasn't in the increment logic. It was in the assumption that "latest by time" equals "latest by value."

The Fix

Instead of relying on created_at ordering, query for the actual maximum code value directly.

$start = "XX00000001";

$maxValue = Model::where('code', 'LIKE', 'XX%')
    ->max('code');

if (!$maxValue) {
    return $start;
}

$num = (int) substr($maxValue, -8);
$next = $num + 1;

return "XX" . str_pad($next, 8, "0", STR_PAD_LEFT);

max('code') operates on the actual data value, not on metadata like created_at. Regardless of when a record was inserted, this always returns the highest code in the table, which is exactly what we need.

One thing worth noting: this fix doesn't eliminate the race condition entirely. Two requests can still call this function simultaneously, both read the same max before either one writes. For a truly bulletproof solution, you'd want a database-level lock (SELECT FOR UPDATE), a UNIQUE constraint on the column to let the DB reject duplicates, or just use AUTO_INCREMENT and format on read. The max() fix is a significant improvement, but it's not atomic.

What I Should Have Done

Looking back, there were two things that would have caught this before it hit production.

1. Write automated tests that simulate concurrent calls.

The bug was triggered by calling this function inside a loop — something that can't be reproduced through the UI or by a non-technical tester. A simple test that calls the function in a loop ten times and asserts all returned IDs are unique would have caught this immediately.

2. Look at the database earlier.

I spent too long staring at the code when the code itself was innocent. The real issue was in the data structure — specifically, the precision of the created_at column. Checking the actual column type and sample data earlier would have pointed me in the right direction much faster.

The most frustrating bugs are the ones where the code does exactly what you told it to. The problem is what you assumed it would do.

How I Fixed a Correlated Subquery That Was Behaving Like an N+1 Problem in Production

Ahmad Fauzan Alghifari — Tue, 14 Apr 2026 07:36:39 +0000

What Happened

A user reported seeing no data after an absurdly long loading time in one of the procurement menus. I was maintaining an e-procurement system for a state-owned enterprise subsidiary in the mining sector and this wasn't just a UI glitch. It completely blocked the user's business process.

From the network tab, the problematic request was just sitting there with endless pending status, until it hit the server's timeout and resulted in 504, effectively sending no data to the user.

The culprit turned out to be a correlated subquery behaving exactly like an N+1 problem: common, easy to miss, and quietly fatal in production. In this post, I'll walk through how I identified the root cause and fixed it.

What is an N+1 Query Problem?

Imagine you have to fetch 500 data from the database. And then, for each of that row, you run another query to compute something like aggregations. That's 1 (the initial fetching) query plus 500 query for each computation. In production, because the data will keep growing, this would be a fatal problem.

// CLASSIC ORM N+1 EXAMPLE
// 1 query
$orders = Order::all();

// N queries — one per order
foreach ($orders as $order) {
    echo $order->supplier->name; // hits the database every single iteration
}

This commonly happens when we use ORM loops like in laravel. But N+1 problem does not happen only to ORMs. Something similar could also happen to the database query itself. Which is exactly what happened in my case.

What Actually Happened

This is a snippet of a long scope code that was implemented with laravel.

->select(
...
CASE WHEN COUNT(po_items.*) > 1 THEN
    (SELECT SUM(total_value)
     FROM po_items
     WHERE po_items.po_id = po.id) 
  END AS sum_val
...
)

Do you see the problem? Yup. Its computing an aggregation function SUM() within the select statement. So for each data that comes from the FROM keyword, let's assume we have 1000 rows, it will run that exact SUM() query for another 1000 times. This will work on small data, but in production environment and database, this query won't survive.

The Fix

->leftjoin (
  SELECT po_id,
    SUM(total_value) as sum_val
  FROM po_items
  WHERE status = 'y'
  GROUP BY po_id 
) as po_item_aggs ON po.id = po_item_aggs.po_id

-- accessing it directly
SELECT po.id, po_item_aggs.sum_val

This is what I did. Instead of doing the aggregations and the subquery inside the select statement, I moved it into another Join operations. This alone removes the computation for each row from the data source. So instead of doing 1000+ query computation, we only did one query for the computation itself.

Results

Metric	Before	After
Response time	~2 minutes / timeout	~15 seconds
HTTP status	504 Gateway Timeout	200 OK
User experience	Blank table, blocked workflow	Normal

The request that was hanging for over two minutes — or not returning at all — now resolves in around 15 seconds. That's not just a performance improvement, it's the difference between a system that works and one that doesn't.

DEV Community: Ahmad Fauzan Alghifari

The latest() Bug That Silently Duplicated Transaction IDs in Production

Background

So What Happened?

The Fix

What I Should Have Done

How I Fixed a Correlated Subquery That Was Behaving Like an N+1 Problem in Production

What Happened

What is an N+1 Query Problem?

What Actually Happened

The Fix

Results