New External Tester Report — First Substantive Feedback in Months
Solai (solai.cdac@gmail.com) provides the first external testing report since Mahendra's earlier reviews. The message confirms basic functionality works but surfaces a user-facing footgun around parallel workers writing to the same output file.
Key Technical Finding: Shared Output Target Corruption
Solai demonstrates that --pipe="gzip > dump.gz" with -j 4 causes multiple parallel workers to independently spawn gzip processes all targeting the same file, resulting in corrupted/truncated output:
gunzip -c dump.gz > dump.sql
gzip: dump.gz: unexpected end of file
This is not a bug per se — the %f placeholder exists precisely to differentiate per-file outputs — but the failure mode when users omit %f from the command template is silent data corruption rather than a clear error. This raises the question of whether:
- The patch should require
%fin the template (or at least warn when it's absent with-j > 1), or - Documentation alone is sufficient to guide users toward correct usage patterns like
--pipe="gzip > dump_%f.gz".
This is a legitimate UX/safety concern that hasn't been raised before in the thread. The existing design assumes users understand that the directory format produces multiple files, but nothing prevents the obvious mistake of specifying a single output destination.
Other Observations (confirmatory, not new)
- Basic single-file dump works correctly (38MB uncompressed, 11MB gzip)
- Error handling for invalid commands works as expected
- No intermediate directory created (confirms streaming-without-staging goal)
- "Broken pipe" / "connection to client lost" backend messages on premature pipe termination are expected but could benefit from UX polish
Significance
This is the first message to break the months-long holding pattern of author-only maintenance rebases. While it doesn't constitute committer review, it does introduce a new design question (guard against missing %f in parallel mode) that the patch author will likely need to address.