Can you explain why the previous approach didn't work?

I think drawing a random length had the downside that the fuzzer could commit to do e.g. 1000 elements even if it has no idea how large these elements will be. This is especially bad if it's generating elements for a list in a list and then decides to do a 1000-element list inside a 1000-element list. Now we throw a non-random coin for every new element, so that if we run out of data, we at least haven't committed already to doing a huge number of extra entries.

I took some more time into further cases where generating a length from simply a usize might be problematic. Arrays are the big issue here since arbitrary has no idea that the array type, which only recurses into the O(1) kind, actually expands to O(N). I experimented with many approaches, but eventually settled on a hardcoded maximum span to ensure that deeply nested arrays don't explode the document. This approach is also reasonably performant during fuzzing.

Codecov Report

Patch and project coverage have no change.

Comparison is base (14734c1) 82.83% compared to head (cbf7fd6) 82.83%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@           Coverage Diff           @@
##           master     #485   +/-   ##
=======================================
  Coverage   82.83%   82.83%           
=======================================
  Files          74       74           
  Lines        9281     9281           
=======================================
  Hits         7688     7688           
  Misses       1593     1593           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.