fix(subnet): handle new error message for deleting subnets with attached resources #923
Conversation
…hed resources The error message we rely on was never part of the API contract. It is soon being changed to the new message I have added. This does not fix any immediate bug, but prepares the provider for the coming months.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #923 +/- ##
==========================================
- Coverage 69.76% 69.74% -0.02%
==========================================
Files 63 63
Lines 7938 7940 +2
==========================================
Hits 5538 5538
- Misses 1701 1703 +2
Partials 699 699
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| if hcloud.IsError(err, hcloud.ErrorCodeServiceError) && | ||
| (strings.Contains(err.Error(), "servers are attached") || strings.Contains(err.Error(), "network has attached resources")) { |
There was a problem hiding this comment.
This feels dirty, any plan to handle this with a not human/changeable error message.
There was a problem hiding this comment.
I do agree, relying on the message is hacky and can (evidently) break from time to time. I do not see any nice workarounds for this though at this time.
Changing the error code would be a breaking change, as we and other implementers might rely on the current code.
🤖 I have created a release *beep* *boop* --- ## [1.47.0](v1.46.1...v1.47.0) (2024-05-02) ### Features * test with Terraform 1.8 ([#919](#919)) ([800a66c](800a66c)) ### Bug Fixes * **ssh-key:** data inconsistency with empty label objects ([#922](#922)) ([7e1bf2c](7e1bf2c)), closes [#921](#921) * **subnet:** handle new error message for deleting subnets with attached resources ([#923](#923)) ([932c47b](932c47b)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
The error message we rely on was never part of the API contract. It is soon being changed to the new message I have added. This does not fix any immediate bug, but prepares the provider for the coming months.