There's a quiet comedy in the way spreadsheets betray us. A user reports that `=SEQUENCE(RANDBETWEEN(1,10))` placed in an empty worksheet throws a `#SPILL!` error roughly half the time. The randomness isn't the problem, and neither is the sequence. The problem is that the formula is asking Excel to commit to a dynamic array size before it has settled on what that size should be. It's a classic race condition, dressed up in business-casual attire.
What makes this curious is that the error isn't tied to a specific number. Testing reveals that any value between 1 and 10 can produce the error in one instance and work perfectly in the next. That's the tell. The issue isn't the magnitude of the spill; it's the volatility of the calculation chain. `RANDBETWEEN` recalculates on every sheet change, and `SEQUENCE` needs a stable reference to know how many rows to claim. When Excel evaluates the formula, it reads the volatile function, gets a value, tries to reserve space, then the recalculation happens again, and the reservation no longer matches. The result is a broken contract between what the formula wants and what the grid can give.
This isn't just a quirk to file away. It's a reminder that dynamic array functions, for all their power, have a dependency on evaluation order that most users never see. We see the same tension in other contexts. When someone tries to visualize neural network learning, they're dealing with systems where the output is only meaningful if the inputs are stable. And when users struggle with Excel not filtering unique values, they're often fighting the same underlying issue: the tool assumes a level of determinism that volatile functions simply don't have. Even in Power Query, where data transformation is more explicit, the principle holds: garbage in, and the pipeline breaks in ways that are hard to predict.
So what do we tell someone who hits this? The fix is to stop nesting volatile functions inside dynamic array functions. Put `=RANDBETWEEN(1,10)` in one cell, reference it directly in `=SEQUENCE(A1)` in another, and the error disappears. That's not a workaround; that's the correct architecture. It forces Excel to evaluate the random value once, freeze it, and then let the sequence size follow without recalculation interference. It's a small change, but it reveals something important about how we should think about spreadsheets: they're not just grids, they're reactive systems with a specific order of operations.
The deeper lesson is practical and a little humbling. Spreadsheet errors are rarely random. They're symptoms of a mismatch between the mental model we have and the way the tool actually computes. The user who posted this wasn't asking for a lecture, they just wanted a solution. But the solution points to a broader truth: the more powerful the feature, the more precise you have to be about when and how it evaluates. If you're building anything in Excel that relies on dynamic arrays, treat every volatile function like a variable that can change under you. Because it can. And it will, about half the time. The takeaway isn't to avoid these tools; it's to respect their boundaries by giving them stable inputs. That's the difference between a formula that works and one that only works until you look away.