fix: honor rclone exit codes in the storage engines

[greglum]

Description

Every rclone invocation in the storage engines ran through three process helpers in AbstractRCloneStorageEngine that called p.waitFor() and discarded the exit code. A failed transfer returned normally, so PushToStorage answered true after a copy that never happened. Listings against the same engine succeed, which makes the false success look like a working pipeline.

The same lines held a second defect: waitFor() ran before either pipe was drained, with stdout and stderr both on Redirect.PIPE. Once a child filled the OS pipe buffer (~64KB) it blocked on write and waitFor() never returned, leaking the calling thread. lsjson --metadata on a large container reaches this.

Changes Made

• Capture the exit code on every rclone invocation and throw IOException on failure (IOException was already declared on every signature, so no caller changes).
• Policy: transfers and config create fail on any non-zero exit. lsf/lsjson and the deletes (delete and purge) tolerate 3 (directory not found) and 4 (file not found), where a missing path is an empty result / no-op rather than an error.
• Drain both pipes concurrently while the process runs (stderr on its own thread), then waitFor() - removes the pipe-buffer deadlock.
• Failure messages name only the rclone sub-command plus capped stderr, and drop stderr entirely for config commands - the config argv carries storage credentials and the message travels back to the caller.
• deleteRcloneConfig logs instead of throwing: every caller runs it from a finally block, so a cleanup failure was replacing the real transfer failure being unwound.
• All nine storage reactors (PushToStorage, PullFromStorage, both syncs, DeleteFromStorage, both lists, GetStorageFileAsBase64, UpdateStorageFileMetadata) append the exception message to their thrown error instead of a fixed string, matching the idiom used elsewhere. The metadata one also stops hiding the UnsupportedOperationException that every non-native engine throws.
• Unit tests for the runner (exit-code enforcement, tolerated codes, deadlock regression with a preemptive timeout, credential-redaction) plus an end-to-end test driving S3StorageEngine.copyToStorage() against a stub rclone whose copy fails.

How to Test

1. mvn test -Dtest=AbstractRCloneStorageEngineUnitTests - all six pass; against the previous code the exit-code test fails ("Expected IOException... nothing was thrown") and the deadlock test times out.
2. Manual: point any rclone-backed storage engine at a bucket the credentials cannot write to and run PushToStorage(...). Before: returns true, file absent. After: pixel errors with rclone copy failed with exit code N - <reason>.
3. Browse a storage path that does not exist (ListStoragePath) - still returns an empty list, unchanged.

Notes

• Behavior change: operations that silently swallowed failures now throw. Flows built on CentralCloudStorage (engine push/pull, image push) will surface rclone failures instead of continuing with missing files - that is the intent, but reviewers should confirm no flow depends on the old silent behavior.
• rclone's contract (https://rclone.org/docs/#exit-code): non-zero only after its own retries are exhausted; 3/4 are the not-found codes tolerated on reads and deletes.
• Known limitation, unchanged from before: there is still no overall process timeout, so a network-stalled rclone blocks the caller. Separate concern if wanted.
• streamJsonOutput/streamListJsonOutput/streamError (protected statics orphaned by the rework) were removed, along with runProcessJsonOutput and the no-tolerance runProcessListJsonOutput overload, which had no callers even before this change; no references exist in this repo or Monolith.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.