DEV Community: Anas Bahraoui

This Spring Boot Endpoint Has 3 Bugs. Can You Find Them?

Anas Bahraoui — Sat, 03 Oct 2026 00:31:51 +0000

Most backend interview practice asks you to write code.

Let's do the opposite.

You're reviewing a pull request for a Spring Boot application.

The endpoint transfers money between two accounts.

The code compiles. It looks reasonable.

But there are 3 important bugs hiding in it.

Can you find all three before reading the answers?

@PostMapping("/transfer")
public ResponseEntity<?> transfer(@RequestBody TransferRequest request) {

    Account sender = accountRepository
        .findById(request.getFromAccountId())
        .orElseThrow();

    Account receiver = accountRepository
        .findById(request.getToAccountId())
        .orElseThrow();

    if (sender.getBalance() < request.getAmount()) {
        return ResponseEntity
            .badRequest()
            .body("Insufficient funds");
    }

    sender.setBalance(
        sender.getBalance() - request.getAmount()
    );

    receiver.setBalance(
        receiver.getBalance() + request.getAmount()
    );

    accountRepository.save(sender);
    accountRepository.save(receiver);

    return ResponseEntity.ok("Transfer completed");
}

Assume:

balance and amount are double
both accounts are stored in a relational database
multiple transfer requests can happen concurrently
there is no additional validation or transaction logic elsewhere

Before scrolling further, write down the 3 problems you'd flag in the PR.

Bug #1: The amount isn't validated

Nothing prevents:

amount = -500

Now look at the calculations:

sender.getBalance() - (-500)
receiver.getBalance() + (-500)

The sender gains 500 and the receiver loses 500.

A financial operation should reject zero or negative transfer amounts before touching either account.

Bug #2: `double` is being used for money

Floating-point numbers cannot precisely represent many decimal values.

Something as ordinary as repeated operations involving values such as 0.1 can introduce rounding errors.

Money should normally use a decimal representation such as Java's BigDecimal, with an explicit rounding policy where necessary.

Bug #3: The balance check and update aren't concurrency-safe

This one is easier to miss.

Imagine the sender has $100.

Two requests arrive at almost the same time:

Transfer A: $80
Transfer B: $80

Both requests can read the original $100 balance.

Both pass:

if (sender.getBalance() < request.getAmount())

Then both continue with the transfer.

Depending on the database behavior and update strategy, you can get lost updates, inconsistent balances, or allow operations that should never have passed together.

The check and mutation need to be protected as one consistent operation, for example with appropriate transaction boundaries and locking/atomic database semantics.

Catching these bugs after someone explains them is easy.

The interesting question is:

Would you have caught them while reviewing the PR yourself?

That's the skill I've been experimenting with in ReviewIQ.

You choose your role, programming language and seniority and get an unfamiliar pull request containing 3 planted bugs.

You review it without seeing the answers first.

Then your review gets graded on what you caught, what you missed and how you explained it.

First 5 reviews are free. No card:

https://reviewiq-ruby.vercel.app/

If you try one, I'm curious what score you get.

I Put 3 Bugs in This Pull Request. How Many Can You Catch?

Anas Bahraoui — Fri, 02 Oct 2026 22:46:57 +0000

Most coding interview practice asks you to write code.

But here's a different test:

Can you spot what's wrong with code someone else wrote?

Imagine this PR just landed on your desk.

The developer added an endpoint for transferring money between two accounts.

Your job isn't to rewrite it. Review it.

There are 3 important problems hiding in this code:

@app.post("/transfer")
def transfer_money(
    sender_id: int,
    receiver_id: int,
    amount: float,
    db: Session = Depends(get_db)
):
    sender = db.query(Account).filter(
        Account.id == sender_id
    ).first()

    receiver = db.query(Account).filter(
        Account.id == receiver_id
    ).first()

    if not sender or not receiver:
        raise HTTPException(
            status_code=404,
            detail="Account not found"
        )

    if sender.balance < amount:
        raise HTTPException(
            status_code=400,
            detail="Insufficient funds"
        )

    sender.balance -= amount
    receiver.balance += amount

    db.commit()

    return {
        "success": True,
        "sender_balance": sender.balance
    }

Stop here for a second.

If this were a real PR, what would you flag before approving it?

Don't scroll until you've picked your three.

Bug #1: The amount isn't validated

Nothing prevents:

amount = -500

Now look at:

sender.balance -= amount
receiver.balance += amount

A negative transfer increases the sender's balance and decreases the receiver's.

At minimum, the endpoint needs to reject zero and negative amounts.

Bug #2: `float` is being used for money

amount: float

Floating-point arithmetic isn't appropriate for exact monetary values.

Values such as 0.1 cannot always be represented exactly in binary floating point, which can create rounding errors across calculations.

Money should generally use a fixed-precision representation such as Decimal or integer minor units.

Bug #3: The balance check and update aren't concurrency-safe

This one is easier to miss.

Imagine the sender has $100.

Two $80 transfers arrive at nearly the same time.

Request A reads:

balance = 100

Request B also reads:

balance = 100

Both pass:

if sender.balance < amount:

Both can then proceed based on stale state.

A production implementation needs transaction-level protection appropriate to the database, such as row locking or an atomic conditional update.

Writing code and reviewing code are different skills

That's the part I find interesting.

You can understand Python perfectly and still miss a concurrency bug while reading somebody else's PR.

And in actual engineering work, you're constantly reading code you didn't write.

I wanted a way to practice that deliberately, so I built ReviewIQ.

You choose your:

role
programming language
seniority

It gives you a code review containing 3 planted bugs.

You review the code like a PR, submit your findings, and get scored on what you caught and what you missed.

The first 5 reviews are free and don't require a card:

https://reviewiq-ruby.vercel.app/

Think you'd catch all 3 in the next one?

Try a review and see what you miss.

DEV Community: Anas Bahraoui

This Spring Boot Endpoint Has 3 Bugs. Can You Find Them?

Bug #1: The amount isn't validated

Bug #2: double is being used for money

Bug #3: The balance check and update aren't concurrency-safe

I Put 3 Bugs in This Pull Request. How Many Can You Catch?

Bug #1: The amount isn't validated

Bug #2: float is being used for money

Bug #3: The balance check and update aren't concurrency-safe

Writing code and reviewing code are different skills

Bug #2: `double` is being used for money

Bug #2: `float` is being used for money