Storage connections are verified the moment you add them
A new connection is now exercised against your storage before it is saved — so a setup that can't do what you need is caught at the point you create it, not on the first job that fails.
Adding a storage connection used to succeed as long as the keys were well-formed. Whether the connection could actually *do* anything — list your buckets, create one, run a backup — only became apparent later, on the first operation that failed. The error you saw then described that operation, not the connection behind it, which is a long way from the actual problem.
Connections are now checked at the point you add them:
- •The connection is exercised for real before it is stored. If it cannot reach your storage, you are told immediately, and told why.
- •Role-based setups must include their role. The Role ARN field is now required, and a role that cannot be assumed is reported as exactly that — with the message your provider returned — instead of surfacing later as an unrelated-looking bucket error.
- •Narrowly-scoped connections still work. A connection that reaches your storage but cannot enumerate every bucket is saved as before — plenty of them are deliberately scoped that way. What is new is that you are told up front that Discover buckets will come back empty for it, so you can add buckets by name rather than staring at a blank panel wondering which end is broken.
Discover buckets is also current immediately. Connecting or removing a connection used to leave the discovery list showing its previous answer for a few minutes — indistinguishable from an account with nothing in it. It now refreshes the moment anything changes, so what you see after connecting is what you actually have.