Resources that throw 409 due to naming conflicts are being retried excessively

[chrisst]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

Some resources throw 409 for retriable errors (sql_instance) but others like compute router throw 409's for things like name conflicts. Currently all 409's are retried but this results in name conflicts in compute router requiring 4 minutes of retries before the error is returned. 409's should be opt-in for retry logic instead of standard.

New or Affected Resource(s)

• google_compute_router

References

• Retry SQL delete calls on 409 #2811

[rileykarson]

I wonder if we could use the error type / message to mark a specific kind of 409 as retriable or not.

[chrisst]

I'm not a fan of using an error message string to drive functionality as it's prone to changing and shouldn't be considered part of the api's interface.

IIRC the sql 409 that we were attempting to retry was pretty generic, which is too bad because I'd much rather opt-in to retrying 4**'s than opt-out.

[chrisst]

🤔 I'm not sure how safe it will be, but we might be able to rely on "reason": "operationInProgress" .

[chrisst]

Just kidding - Looks like the Sql Error response is wrapped into a googleapis.error where it removes any of the fields that I feel comfortable relying on:
https://github.com/googleapis/google-api-go-client/blob/master/sqladmin/v1beta4/sqladmin-gen.go#L5821-L5823

When Sql instance is generated and we move away from the client library we'll have access to the raw response, but looks like for now the only choice we have is to string parse the error response 🤕

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!