Case study
Why your main list screen suddenly stops opening
A client's main list stopped opening while every other page worked. The cause was one record far larger than the rest, and the same fault was failing quietly in a background task.
Key takeaways
- A list that suddenly stops opening often has one oversized record behind it, not a change someone made.
- Databases sort rows whole, so a single record bigger than the memory allowed for the sort fails the entire page.
- A list should load only what it displays; long documents and files belong to the page that opens one item.
- The same cause is often failing quietly in a scheduled background task that nobody is alerted about.
- Raising a memory limit moves the problem to the next, larger record instead of removing it.
A client's team opened the main list in their internal system and the page showed an error instead. Nobody had changed that screen, and every other page worked. The cause was a single record that had grown far larger than the rest.
What a list that will not open costs the team
The main list is where a team finds, opens and finishes its work, so when it stops opening the whole team stops with it. For this client, that list holds the items the team works from, newest at the top. The page they had used without thinking now showed an error and nothing else, while every other screen behaved as usual.
That combination, one broken screen and nothing changed, is what makes these faults look mysterious. In our experience they come back, because the fault grows with the data rather than with anything a person did. The same symptom turns up in any growing system: an internal tool list broken, a CRM list not opening, a screen the team relies on all day.
Why an admin list page not loading often comes down to one big record
To show the newest items first, the database sorts the rows, and it sorts them whole. A database is the store where an internal system keeps its records, and a sort happens whenever you ask for records in a particular order. For a sort of this kind the database sets aside a fixed amount of memory as working space, and it does not weigh each row before starting: every row goes into the sort in full, with everything it holds. One row larger than that allowance fails the entire list, however small the others are.
That is why growth in the size of records breaks things as surely as growth in their number. Adding records slows a list down; adding one unusually large record can stop it opening at all.
What our engineer found
The error came from the database and said it had run out of memory for sorting. Because the newest items were shown first, the rows were being sorted, and each row carried a heavy field along with the title and the date. That field was a long block of text the list never displayed.
Those fields are usually small. The team had recently started creating a new kind of item, and one of them carried a field far longer than anything before. The database sets aside a fixed amount of working memory for a sort of this kind, and that one row no longer fitted, so the whole list failed. Raising the database memory would only have moved the limit until the next, larger record.
The turning point was a plain question: does the list need that field at all? It shows a title, a state and a date, nothing more.
Searching for the same error elsewhere told the rest of the story. The same fault was failing silently in a background task, a job that runs on a timer with nobody watching it. Nobody had seen it. The team only knew about the screen in front of them.
What we changed
We made the list read each item without the heavy field, so the page loads only the title, the state and the date. The field is read when someone opens that item, and only then. We also added an index, a lookup structure that keeps the items in order of their last change, so showing the latest first needs no sorting at all.
Shortly after, the same thinking covered the whole system: unless specific fields are asked for, a request for these items now leaves the heavy field out by default, the background task's requests included. Opening a single item still reads the field in full. A new automatic check now catches it if either the list or the task starts asking for the field again.
What the business has now
The changes went live on the client's system the same day. The list opens again and the background task runs again. An item of any length can no longer break either of them, and opening a single item works as before.
What you can check yourself
- Ask your developer what your busiest list screen loads for each row, and whether it loads anything the screen never shows.
- Ask whether anyone is told when a background task fails, and how you would find out today if one had been failing quietly.
- If someone suggests raising a memory limit to make an error go away, ask first what the screen actually needs; a higher limit only waits for the next, larger record.
- When you start a new kind of work in your system, such as much longer documents or files, ask whether any screen could choke on the size of one item.
- Do not stop at the screen someone complained about. Ask whether the same fault sits in tasks nobody looks at.
What to do next
Take the list your team uses most and ask the question that unlocked this one: what does this screen need for each row, and what is it loading anyway. Then ask for a way to learn when a background job fails, rather than finding out from a broken screen. Tracing a fault like this to its cause is the kind of work our engineers do for clients, and it usually starts with one plain question about what a page is really asking for.
Questions people ask
How do I find out if a background task has been failing quietly?
Ask whoever looks after your system whether failures in scheduled jobs are recorded anywhere and whether anyone is alerted. If the answer is that nobody would know, that is worth fixing first, because a failing job produces no visible symptom until someone depends on the result.
Why did our list screen break when nobody changed anything?
Because the data changed, not the screen. A list that sorts its rows makes the database hold each row in working memory, and one record that grows beyond the space allowed is enough to stop the page. The screen itself can stay untouched for a long time before that happens.
How can one record stop a whole page from loading?
The database sorts all the rows together, and it does not skip the large parts of a record while sorting. If one row is bigger than the memory set aside for that sort, the whole operation fails, so the page has nothing to show. The other records being small does not help.
Should we just increase the database memory limit?
Raising the limit can make the error disappear for now, but it does not answer why the page was loading so much. The next longer record can cross the new limit, and the same failure returns. It is better to ask what the screen actually needs and load only that.
What should a list screen load for each row?
A list should load only the fields it displays, such as a title, a state and a date. Long text, files or production details belong to the page that opens one item. That keeps the list fast and stops one large record from breaking it.