DEV Community: Huzaifa Iftikhar

15 Bugs That Said Everything Was Fine

Huzaifa Iftikhar — Sat, 26 Sep 2026 06:50:01 +0000

A database told me it had saved my data.

It had not. The write was rolled back. No error. No warning. No exception. Just the word "success" and an empty table.

That bug is now fixed, in Microsoft's Entity Framework Core, because a student in Lahore reported it and wrote the patch.

I have had 15 contributions merged into open-source projects: Google, Microsoft, Apache, the OpenJS Foundation, Red Hat. Together those repositories have more than 890,000 GitHub stars. Twenty-one more of my fixes are waiting upstream right now.

I have never met any of those maintainers. None of them know what I look like. They read the code and merged it.

Here is what I have learned, and how you can start.

THE PATTERN: THE WORST BUGS SAY NOTHING IS WRONG

When you start looking for bugs, you look for crashes. Crashes are easy. Something breaks, a red message appears, everyone can see it.

The dangerous bugs do the opposite. They fail, and then they tell you everything is fine.

Look at the ones I found:

A database said "saved" when nothing was saved.

In EF Core's SQLite provider, two common commands reported success even when a later statement had failed. A busy commit was retried in a way that answered "OK" after the first attempt had already reported the problem. Result: your write is gone and your program is happy. That fix went into release 12.0-preview1.

A build said BUILD SUCCESS when nothing was built.

Apache Maven's concurrent builder was catching one kind of failure but not another. A step could throw, the build could produce nothing, and the screen printed the green success message. A reviewer reproduced it and found a second path to the same problem.

Fields vanished from saved data.

In Google Gson, a list declared with a wildcard type was written out using the declared type, not the real one. Subclass fields disappeared. A list of strings came out as [{},{}] — empty objects where your text used to be. No error. Just quietly less data than you put in. It was merged after passing Google's internal test suite.

A crash that had been waiting since 2022.

Also in EF Core: reading a stream from a certain kind of column passed three nulls into a native SQLite call, which answers "you are using this wrong," so the read threw as soon as another computed column shared the query. That issue sat open for over four years.

A program could die while cleaning up.

Pruning an idle pooled SQLite connection could take down the whole process, because a cleanup hook was cleared through a handle that was already closing.

There is a lesson in that list.

Anywhere a system reports success, ask who checks that the success is true.

That question, asked patiently, has found me more real bugs than any clever technique.

THE OTHERS

Not everything is dramatic. Good contributions come in all sizes:

Jest (45.5k stars): an import path starting with # was being read as a web address fragment, so a whole category of package imports broke. Shipped in v30.5.1.

Microsoft GitHub spec-kit (138k): a command name containing a hyphen could not be reached at all. Three people submitted fixes; mine was chosen as the canonical one. A second fix made a missing file fail early with a clear message instead of late with a confusing one.

Playwright (96.5k): a filter control was a plain div, so keyboard users could not reach or open it. An accessibility fix, and one I care about personally.

Quarkus (15.9k, Red Hat): request filters were reordered so their priorities ran backwards.

BenchmarkDotNet (11.5k): you could not pin a benchmark to any CPU above the 32nd, and one case crashed with a raw overflow error instead of a normal message.

LangChain (146.8k): a documentation block that contradicted itself.

That last one is a documentation fix, and I list it on purpose. It counts. Every big project has wrong docs, and fixing them is the easiest honest way to get your first merge.

WHY THIS MATTERS MORE THAN A CERTIFICATE

I could not get an internship at Google. I do not have a degree from a famous university. I studied at the University of Central Punjab in Lahore.

But my code is in Gson, which Google maintains. My fix shipped in Jest. My name is in the EF Core release history. Anyone can check.

Here is the quiet truth about open source: nobody asks where you are from.

There is no CV screen. There is no interview. There is a patch, and a test, and a maintainer who decides whether your reasoning is right.

For people who get filtered out early by everything else, that is the fairest door in this industry.

HOW TO GET YOUR FIRST MERGE

This is the part I wish someone had written for me.

Do not start by looking for a project. Start by using one.

Use a library, hit something strange, and follow it. Every fix I have listed started as "wait, that is weird."

Read the issue tracker, sorted by oldest.

Old open issues are gold. They are real, reproduced, still broken, and everyone else got bored. My EF Core stream fix had been sitting since April 2022.

Reproduce it in the smallest possible program.

Before you write a single line of the fix, write the twenty lines that prove the bug exists. Maintainers live by reproductions. A good one makes them want to help you.

Find the real cause, not the place it hurts.

The error appears in one place. The mistake usually lives somewhere else. Read the code path backwards until you can explain why, in one sentence, out loud.

Make the smallest change that fixes it, and add a test.

Your patch is competing with the maintainer's time. Big patches look expensive. A tiny patch with a test that fails before and passes after is easy to say yes to.

Write the pull request like a short story.

What happens now. What should happen. Why. What you changed. How you tested. No drama, no essay.

Expect silence, and do not take it personally.

Some of mine were merged in days. Some sat for months. One was superseded by someone else's patch, and the fix shipped with my name as co-author. Twenty-one are still open right now. That is normal. It is not rejection.

Be polite when a maintainer corrects you.

They know the codebase. You do not. On one of my Maven fixes, a reviewer found a second failure path I had missed, and the final fix was better than my original. That is the system working.

START THIS WEEK

You do not need permission and you do not need to be an expert.

Pick one library you actually use. Open its issues. Sort by oldest. Find one you can reproduce. Write the twenty lines that prove it. Then read the code until you understand why.

That is the whole method. I have used it fifteen times.

The first merge is the hardest one. After that you will never again wonder whether you are a real programmer, because the answer is sitting in someone else's release notes.

Huzaifa Iftikhar is a software engineer in Lahore, Pakistan, and a 2026 Computer Science graduate. His merged contributions are at github.com/HuzaifaChaudary.

We Built a Food Delivery Network in Pakistan Without a Payment Gateway

Huzaifa Iftikhar — Sat, 26 Sep 2026 06:42:32 +0000

There is one word in our database that we never use: jazzcash.

It sits there as a legacy value in an old enum, left over from the plan we started with. That dead word shaped our entire final year project.

We wanted to build SmartBite: a marketplace where home chefs cook from their own kitchens and sell to customers nearby. Riders deliver. Ingredient vendors supply the chefs. Admins keep the platform honest.

Every tutorial online says the same thing: plug in a payment gateway and you are done. In Pakistan, that usually means JazzCash. We went a different way and built our own money flow instead.

This is how we built the whole system, and what it taught me.

SmartBite: Homemade Meal Delivery Network — BSCS Final Year Project, Group F25CS010, University of Central Punjab. Advisor: Dr. Rabia Tehseen. Team: Abdullah Maqsood, Huzaifa Iftikhar, Moizz Ahmad. I worked on the mobile apps and the recommendation engine.

THE MONEY PROBLEM

A gateway is not just an API key. It is a merchant account, a registered business, paperwork, and an approval process. A three-student team building a final year project has none of that.

So we dropped the gateway entirely and designed a payment flow around what people here already use every week: their own bank app.

Here is what happens when a customer checks out:

The screen shows our merchant bank account (IBAN) and a QR code for the exact amount.
The customer opens their own banking app and sends the money. A normal Raast or bank transfer. The same thing they already do every week.
The customer uploads proof — a screenshot or the transaction receipt.
An admin checks the transfer against the real bank account and approves or rejects it.
Only after approval does the order move forward.

No gateway. No API keys. No monthly fee.

One small decision saved us from a whole class of bugs: we store every amount as an integer in paisa, never as a decimal. Money in floating point is a famous way to lose a rupee here and there and never find it again.

Is manual verification slower than a card payment? Yes. But it works today, in this country, with no company registration. Sometimes the right engineering answer is the one that can actually run.

FIVE APPS, ONE BACKEND

SmartBite is not one program. It is five, each one runnable on its own:

server/
The API everything talks to. Built with Node.js, Express 5, TypeScript, Mongoose (MongoDB), and Socket.IO.

web-dashboard/
Chef, vendor and admin portals. Built with Next.js 15, React 19, and Tailwind CSS.

mobile-app/
Customer and rider app in one project. Built with Expo SDK 54, React Native 0.81, and expo-router.

ai-engine/
Meal recommendations. Built with Python 3.11, FastAPI, and scikit-learn.

landing/
Public website. Built with Next.js 15 and Tailwind CSS.

The two frontends share one backend and one users collection. So an account made on the web signs in on mobile. That sounds obvious. It is the kind of obvious thing that breaks quietly if you do not plan it on day one.

The customer app and the rider app live inside one Expo project, as two route groups. Two experiences, one codebase, one build to maintain. For a three-person team, that decision paid for itself many times.

THE AI ENGINE CAN DIE AND NOBODY NOTICES

Our recommendation service is a separate Python process. That worried me. A separate service is a separate thing that can fall over at 2 a.m. during the demo.

So we made it optional.

The backend asks the AI engine for recommendations. If the AI engine does not answer, the backend quietly falls back to a popularity ranking and the app keeps working. The customer sees meals either way. Nothing breaks. Nobody sees an error.

We did the same thing with maps. Google Maps is integrated on the server, with a plain straight-line distance fallback built in. The entire system runs with no paid API keys. For a student project that has to work on a demo laptop in a viva room with bad internet, this mattered more than any feature.

If I could teach one idea from this project to a younger student, it is this: every external thing you depend on should have a boring backup. Build the backup first. Then you can sleep.

HOW THE RECOMMENDATIONS ACTUALLY WORK

There are two halves.

The live half runs inside the app:

Every meal is turned into a text document (name, description, tags) and compared using TF-IDF with cosine similarity. If you ordered biryani, you get things that look like biryani in word-space.
Meals nobody has ordered yet cannot be compared to your history, so they are ranked by popularity, using a Bayesian average, not a raw star rating. This matters. One 5-star review from the chef's cousin should not beat 4.6 stars from forty real customers. The Bayesian prior pulls small samples toward the global average until they earn their score.
Every recommendation carries a reason in plain words: "Similar to meals you ordered recently", "Popular dish (4.6/5 from 12 reviews)", or "New on SmartBite."

That last part was not in the requirements. I added it because a recommendation you cannot explain is a recommendation nobody trusts.

The offline half is a proper collaborative-filtering model. We trained an SVD model on the public Food.com dataset from Kaggle (1.1M+ ratings, 230K+ recipes), filtered down to 150,000 interactions:

120,000 for training
30,000 for testing
14,518 users
14,972 recipes
100 factors
20 epochs

Results on the held-out test set:

RMSE: 0.936
MAE: 0.536
Precision@10: 0.913 (relevance threshold 4.0)

The honest bit: a brand-new marketplace has almost no rating history of its own. Collaborative filtering needs a crowd. So the live system leans on content similarity and popularity, and the trained model proves the method works and is ready for when there is real data.

Writing that in the report felt like admitting weakness. It is not. It is knowing which tool works at which stage.

DELIVERY: THE PART THAT HAS TO WORK IN REAL TIME

This is the chain, and we tested every link of it with live requests against a running server:

The chef marks an order ready for pickup.
The dispatcher computes and sends offers to nearby riders.
A rider accepts. The order becomes out for delivery and the rider is attached to it.
The rider's phone sends its GPS position to the server as they move.
The customer's app asks for the order every 15 seconds and gets back the order status, the chef's kitchen location, and the rider's latest position.
The pin on the customer's map moves.
Delivered.

One bug from that testing is my favourite thing in the whole project.

The rider's active delivery screen did not refresh. When a chef or admin changed the order status, the rider saw nothing until they pulled down to refresh manually. Everything on the server was correct. The data was right. The rider just never saw it.

We found it by walking the flow like a real user instead of reading the code.

A system can be completely correct and still be broken for the person using it. No test we had written would have caught that.

WHAT I WOULD TELL A STUDENT STARTING THEIR FYP

Choose constraints, then design. We could not have a payment gateway. That was not a limitation to complain about; it was the most interesting design problem in the project.
Make every dependency optional. AI engine down, no maps key, no internet — it should still run.
Build the demo path first. Seed data, demo logins, one script that starts everything. You will run it a hundred times.
Test like a user, not like a programmer. Click through the whole flow on a real phone. That is where the real bugs live.
Store money as integers. Always.
Write down why. Six months later, in the viva, "why did you choose this?" is the question you get asked. The answer should already be written down.

We shipped it: five applications, one backend, live delivery tracking, a working payment flow with no gateway, and a recommendation engine that explains itself.

And the thing that made it good was not the AI. It was the boring decisions.

Integer paisa. Fallbacks everywhere. One account across two apps. A backup for every dependency.

The clever part gets you marks. The boring parts get you a system that still runs on demo day.

Huzaifa Iftikhar is a software engineer in Lahore, Pakistan. SmartBite was his BSCS final year project at the University of Central Punjab.