When dumping a table with dump=pretty, a record whose value is a zero-length u-format item is printed with the value of the preceding record instead of as empty. The -x (hex) and -j (json) formats render the same data correctly.

Steps to Reproduce

Table with key_format=q,value_format=u containing, in key order: {2: "A"}, {3: <empty>}, {5: "B"}, {6: "C"}.

Example

Results without test fix:

> wt -h /data/db/job0/mongorunner/container_operations-0 -r dump -p -f ../scratch/index-multiintkeys.hex table:index-multiintkeys
> cat ../scratch/index-multiintkeys.hex
...
Data
2
A
3
A
5
B
6
C

Expected results with test fix:

> wt -h /data/db/job0/mongorunner/container_operations-0 -r dump -p -f ../scratch/index-multiintkeys.hex table:index-multiintkeys
> cat ../scratch/index-multiintkeys.hex
...
Data
2
A
3
(null)
5
B
6
C

Root Cause

_wt_buf_set_printable_format() (src/support/scratch.c) reuses a single output buffer (cursor->value) across records. For a zero-length u/U field it hits if (pv.u.item.size == 0) break; and appends nothing. _wt_buf_init(buf, 0) sets buf->size = 0 but does not clear or NUL-terminate buf->mem, so the function returns buf->data still pointing at the prior record's formatted string.

Non-empty values are unaffected because _wt_buf_catfmt() NUL-terminates on append; the hex path is unaffected because _wt_raw_to_esc_hex() always writes a trailing NUL even for size 0.

Impact

Silent data misrepresentation in wt dump -p output for any table that stores empty values (e.g. MongoDB containers). Tooling and tests that verify data via the pretty dump observe the wrong value.