You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix -o for large and unfinished batches, usage exit codes, and CSV columns - #35
-o silently wrote a header-only file for batches that return download_file or are still verifying, and usage errors exited 1 with unknown even though the README promises 4 and invalid_input for bad input. This also makes account status --json pass the API body through like the other commands, shows the stored login email in status for API-key logins, and gives CSV exports every verify field with blanks where the API sent nothing.
…lumns
`-o` silently wrote a header-only file for batches that return `download_file` or are still verifying, and usage errors exited 1 with `unknown` even though the README promises 4 and `invalid_input` for bad input. This also makes `account status --json` pass the API body through like the other commands, shows the stored login email in `status` for API-key logins, and gives CSV exports every verify field with blanks where the API sent nothing.
A 1M-row `download_file` export was parsed into memory whole before conversion, which could reach gigabytes. CSV output now converts the download one row at a time through the same encoder inline results use, and atomic writes stream to the temp file.
Leaf commands using plain `cobra.NoArgs` still exited 1 with `unknown`, so the root now wraps every command's `Args` check instead of relying on each command to opt in. A trailing `--json=false` after a bad flag also now wins over an earlier `--json`.
The README spelled out download handling, CSV column order, and status display rules that users never act on; `-o` and the error codes are already documented where they matter.
A completed large batch printed a ~1,700 character presigned URL with broken indentation. It now shows the same per-state summary as small batches, built from `total_counts`, and points to `-o`; the URL stays in `--json` for scripts.
`--partial -o` on a batch with nothing verified yet still wrote a header-only file, and a large batch that reports only top-level `total`/`processed` showed "Verified 0 emails". The `--quiet` help now says it hides hints, progress, and status messages, since results still print.
Batch summary drops duplicate counts from typed aggregate
internal/api/types.go:59
total_counts also contains duplicate (see the established API fixture in cmd/batch_e2e_test.go:195), but the typed aggregate drops it. A download-only batch with 10 state results and 5 duplicates can therefore print Verified 15 emails while the displayed breakdown sums to 10. Model the duplicate count and account for it in PrintBatchSummary (either display it or exclude it from the verified total according to the API semantics).
The server's `processed` count includes duplicates, which carry no state, so a batch with duplicates claimed more verified emails than its breakdown added up to. The count now matches what was verified, and skipped duplicates are noted.
Addressed the duplicate count finding in 228c004. The backend computes processed as the four state counts plus duplicate, so the summary now reports processed - duplicate as verified and notes skipped duplicates when there are any, keeping the headline equal to the breakdown.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Download-only batches without count fields are incorrectly reported as having verified zero emails.
0 open findings
Previously missed (1)
In code that hasn't changed since last review
Avoid reporting zero verified emails when count is unavailable
internal/output/human.go:426
A download-only response can omit both progress shapes (the new TestBatchGet_DownloadFileHint fixture does exactly this). In that case verified remains zero, so the completed large batch is now reported as Verified 0 emails. Track whether a count was actually available and render a count-free completion result (for example, Batch complete) when it was not.
Not changing this. A download-only response without counts cannot come from the API: batch_payload and sample_batch_payload in the backend always set total_counts, and download_file is only ever added to that same payload. Only a breaking API change would produce that shape, so the fallback would be dead code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
-osilently wrote a header-only file for batches that returndownload_fileor are still verifying, and usage errors exited 1 withunknowneven though the README promises 4 andinvalid_inputfor bad input. This also makesaccount status --jsonpass the API body through like the other commands, shows the stored login email instatusfor API-key logins, and gives CSV exports every verify field with blanks where the API sent nothing.