API Fixes: Names Stay Fixed, Caches Wait Out Migrations
Renaming a database or cache through the API is now refused instead of creating an empty copy, and a cache that is moving to the managed operator cannot be changed until the move is confirmed or rolled back.
What's changed
- PUT /api/v1/database/{id} with a new name is now refused with a 422 that explains a database keeps the name it was created with. Before, a new name could deploy a second, empty database and leave the original running unmanaged. Sending the current name alongside other changes still works
- PUT /api/v1/cache/{id} refuses a new name the same way, with the message The name cannot be changed after the cache is created
- The danube CLI sends the same request from database update --name and cache update --name, so those options now get the same refusal
- While a cache is moving to the managed operator, the API refuses to edit, delete, start, stop or force-stop it, with the sentence the console shows: an edit gets a 409 and the other actions a 422. Try again once the migration is confirmed or rolled back