-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing test(s): CloudIdentityGroup still exists #10001
Comments
Google Cloud-TestAccCloudIdentityGroup_update - 43.2% of success rate (50 failures) Google Cloud Beta-TestAccCloudIdentityGroup_cloudIdentityGroupsBasicExample - 47.2% of success rate (47 failures) |
b/262375687 |
Current error looks like this (but appears to be the same underlying problem):
|
This also occurs for TestAccDataSourceCloudIdentityGroups_basic, and all three use the same Also confirmed that it is possible for all 3 to fail in the same build: https://ci-oss.hashicorp.engineering/viewLog.html?buildId=374114&tab=buildResultsDiv&buildTypeId=GoogleCloud_ProviderGoogleCloudGoogleProject#testNameId-8784264308608877604 and for all 3 to pass in the same build: https://ci-oss.hashicorp.engineering/viewLog.html?buildId=373561&tab=buildResultsDiv&buildTypeId=GoogleCloud_ProviderGoogleCloudGoogleProject |
I can't reproduce this with locally-running code, and can't readily see where the issue would be coming from, so I've created GoogleCloudPlatform/magic-modules#7308 to see if VCR can reproduce the errors. Worst case if we can't determine exactly what is wrong: we could try using different configs for |
Also related, there are some APIs that throw a 409 when there are multiple concurrent writes, not necessarily for the same exact resource. This API returns the The solution for other APIs seems to be a retry on 409, although if the error message is actually incorrect in this case, it could be hard to distinguish a retryable 409 from a non-retryable 409. |
I'm going to try running the all of the tests that use a If the issue is resolved, then that would likely confirm a concurrency issue, and we probably want to implement a mutex as well. If the issue is not resolved, then we can likely rule out a concurrency problem, and will have to revisit this for a fix. In that case, we should also revert the change that runs these tests serially. |
This has been passing in both providers since it was introduced, so considering it resolved. Will follow up with a separate ticket to handle a mutex. |
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. |
Affected Resource(s)
Failure rate:
Impacted tests:
Nightly builds:
Message:
The text was updated successfully, but these errors were encountered: