The Error Page Is Gone
If you had the Quotes or Invoices page open today, you may have seen a stark grey error page reading Error 1102 — Worker exceeded resource limits. For some of you it appeared the moment you opened the page. For others it was stranger: the page loaded fine, you read it, you went to click something — and it had replaced itself with an error, without you doing a thing.
That second version is the one that explains the whole problem, and it's fixed.
What Was Happening
Both pages refresh themselves in the background so that when a colleague sends a quote or marks an invoice paid, you see it without hitting reload. That part is by design and it stays.
What was not by design: the Quotes page had started doing that refresh three times over, on three separate schedules, each one re-fetching and re-sending the entire list. Nothing was coordinating them, so they piled up. A page you simply left open — while you took a call, or switched to your email for ten minutes — kept quietly redoing that work over and over until the server handling it ran out of room and gave up. Hence an error appearing on a page nobody had touched.
The refresh now happens once, on one schedule, with repeat requests folded together instead of stacking. Same freshness, a fraction of the work. The Quotes page in particular now does roughly a third of what it was doing.
Searching Invoices Got Safer Too
Separately, searching your invoice list had no upper bound on how much it would pull back at once. On a small list you'd never notice. On a few years' worth of invoices it was capable of triggering the same error — and worse, the "showing a limited number of results" notice that was supposed to warn you about large lists wasn't actually limiting anything. It reported a cap it never applied.
Invoice search is now genuinely bounded, and that notice now means what it says.
Being Straight With You
This is the second time this error has reached you. A fix in an earlier release addressed a similar failure on the quote detail page, and we believed the cause was understood. It wasn't — we'd fixed something adjacent to the real problem. Measuring it properly this time showed the page we'd blamed was not the heaviest one, and the page we'd never suspected was the one doing triple the work.
We've also found that this specific class of failure never showed up in our error reporting at all — when it happens, the report goes down with the request that would have sent it. That blind spot is why it took two reports to catch. Closing it is our next piece of work, so the next one surfaces on our side before it surfaces on yours.
If you see this error again after today, please tell us — and if you can, mention whether the page had been sitting open first. That detail is what cracked this one.