Storage Connection Test

Overview

Operators can validate storage credentials (S3, Azure, GCS, FTP) before saving a configuration, reducing failed protect jobs caused by misconfigured storages.

How it works

1. The storage editor exposes a "Test connection" button calling POST /config/storage/test-connection.
2. The backend runs a real upload probe per provider (_bcyip_iptower_/upload_test_<timestamp>.txt).
3. On failure, the API returns a BadRequestException carrying the provider's own error message; the UI shows it in a floating error popper.
4. Save is disabled until the test passes for the current configuration snapshot.
5. A read-only storage summary page (/storages/:name) offers inline test, Edit, and Delete.

Key files

• src/app.controller.ts — POST /config/storage/test-connection
• src/protocol/storage/storage.service.ts — testConnection dispatcher
• src/protocol/storage/{amazon-s3,azureBlobStorage,google-cloud-storage,ftp}/*.service.ts — per-provider probe
• ui/src/pages/storages/StorageEditor.tsx — test UX + Save gate
• ui/src/pages/storages/StorageSummary.tsx — read-only summary + inline test

Technical decisions

• GCS accepts either inline credFileContent or an existing keyPath (on edit), so re-testing an existing storage does not require re-uploading credentials.
• TestStorageConnectionDto is separate from CreateStorageDto (keyPath / GCS creds optional) so a partial form can be validated.
• FTP errors propagate the SDK message instead of a generic wrapper for actionable feedback.

Next steps

• Cache the last successful test result per storage to avoid re-probing on minor edits