PORTFOLIO

· 1 min read

The bug wasn't where I looked first

An admin dashboard that could not load its own data, and what it taught me about where to look.

Fortune Cookie is a promotional web app I built for Billionaire Gaming. A participant enters their details, opens a virtual cookie and gets a reward or a hard-luck message. Behind it sits an admin dashboard for managing participants and rewards.

One day the dashboard stopped loading participant records. The data was in the database. The dashboard just could not show it.

My first guess was wrong

I assumed the frontend was at fault, so I started with the queries the dashboard was sending. They looked fine. I kept looking at them anyway, because that was where the problem appeared.

It was not where the problem lived.

What was really happening

Each participant record was coming back with its reward image attached, encoded as base64 text. One record like that is harmless. A whole list of them makes a very large response, and the requests were timing out before the dashboard received anything.

The fix was to stop sending images with the participant list. I separated the image data from the participant records and tightened the queries so the dashboard only asked for what it needed to display.

A second bug in the same place

While I was there I found another one. When someone entered a second time, the app showed the name they had just typed instead of the name saved from their first entry. I traced it to a database function that was not returning the original participant name, corrected the function, and fixed the application logic that read it.

What I took from it

The screen is where a problem shows up. It is often not where the problem is. Now, before I blame the frontend, I check the whole path: the database, the function, the response, and only then the page.