Function debug_json 

pub fn debug_json(
    source: &str,
    fuel: Option<u64>,
    deadline_ms: Option<u64>,
    moments: usize,
) -> String

Runs source as run_json does, watched by a record::Recorder, and answers everything run_json answers plus the recording under debug.

{…as run_json…,"debug":{"moments":[…],"functions":[…],"kept":int,
                        "limit":int,"bytes":int,"truncated":…}}

debug is null for a source that did not compile, because there was no run to record and an empty recording of a program that never started reads as a program that did nothing.

moments is how many moments to keep; zero asks for record::MOMENTS, and anything past record::MOST_MOMENTS is clamped to it. record’s module documentation says what a moment is, what bounds it, and why a browser gets a recording rather than a debugger it can step.

One blob, not pieces

A recording is much larger than a compile result, so the alternative was considered and refused: a first call answering the moments’ outlines and a second answering one moment’s detail. Two things decided it.

A paged ABI needs the module to hold the recording between calls, and abi exists partly to have no module-level state — its length prefix replaced a “how long was the last answer?” export precisely so that two calls in flight have nothing to race over. Holding a recording would put that back, and worse, because the state would now be the size of the recording rather than of a number.

And the size a page actually pays is not the size paging would save. What makes a recording large is repetition, and the two repeated things — a function’s disassembly and its name — are interned into functions once each. What is left per moment is what genuinely differs between moments. A recording of the example program is a few tens of kilobytes; see web/README.md for what larger ones measure. The bound that keeps it from growing without limit is record::BYTES, and a bound is a better answer to “this could be huge” than an ABI that hands over a huge thing slowly.