fix: download-all returns error on partial failures#50
Conversation
downloadAllAttachments was returning nil even when individual file downloads failed, causing the CLI to exit 0. Callers (and scripts) had no way to detect partial failures.
There was a problem hiding this comment.
Code Review
This pull request introduces error reporting for partial failures in the attachment download process by checking the error count before returning. However, the current implementation bypasses this check when JSON output is enabled, which needs to be addressed to ensure consistent exit codes.
The --json code path returned early before the error check, so download failures with --json still exited 0. Co-authored-by: gemini-code-assist[bot] <gemini-code-assist[bot]@users.noreply.github.com>
|
@gemini-code-assist — good catch on the JSON early return. Fixed in 94cdf73: the |
|
Thanks for the update, Hinne1. The logic in |
Merging this branch will not change overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. |
Summary
--download-allwas returning exit code 0 even when individual file downloads failedContext
Discovered while building a Confluence space backup script — the script's retry logic couldn't detect failed attachment downloads because the CLI always exited 0.
Test plan
atl confluence page attachment <id> --download-allwith a page that has attachments returns 0 on success