You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe that the samples already are correctly ordering the creations and deletions. That said, the race condition, multi-threading, and being unable to delete non-empty resources are the source of pain here.
Yeah, if we just put 8 rpcs serially as we do in test_gateway_listen_for_bound_device_configs the success rate will be a product of those 8 rpcs (create/delete for 4 resources).
For example, if the success rate of those rpcs are 0.9, the whole success rate will be 0.9^8 = 0.43046721. If we retry this test 5 times, the success rate will be 1 - (0.56953279^5) = 0.94007698385.
Instead, we should have 4 fixtures with retrying each creation/deletion. If we retry 5 times for example, the success rate for each rpcs with the retries will be 1 - 0.1^5 = 0.99999, so the whole success rate will be 0.99999^8 = 0.9999200028. Without retrying the test itself, it is already more robust than the above example :)
Activity
flaky-bot commentedon Feb 12, 2020
Test passed in build fbcdef1 (https://source.cloud.google.com/results/invocations/04397697-dd91-4cfb-a092-94cdeb1e87b2)! Closing this issue.
flaky-bot commentedon Feb 26, 2020
Looks like this issue is flaky. 😟
I'm going to leave this open and stop commenting.
A human should fix and close this.
iot.api-client.mqtt_example.cloudiot_mqtt_example_test: test_gateway_send_data_for_device failed
buildID: ff9682e
buildURL: Build Status, Sponge
status: failed
19 remaining items
gguuss commentedon Apr 15, 2020
I believe that the samples already are correctly ordering the creations and deletions. That said, the race condition, multi-threading, and being unable to delete non-empty resources are the source of pain here.
tmatsuo commentedon Apr 15, 2020
Yeah, if we just put 8 rpcs serially as we do in
test_gateway_listen_for_bound_device_configsthe success rate will be a product of those 8 rpcs (create/delete for 4 resources).For example, if the success rate of those rpcs are 0.9, the whole success rate will be 0.9^8 = 0.43046721. If we retry this test 5 times, the success rate will be 1 - (0.56953279^5) = 0.94007698385.
Instead, we should have 4 fixtures with retrying each creation/deletion. If we retry 5 times for example, the success rate for each rpcs with the retries will be 1 - 0.1^5 = 0.99999, so the whole success rate will be 0.99999^8 = 0.9999200028. Without retrying the test itself, it is already more robust than the above example :)
[iot] fix: use fixtures for resource setup/teardown (#3428)
flaky-bot commentedon Apr 27, 2020
Oops! Looks like this issue is still flaky. 😬
I reopened the issue, but a human will need to close it again.
commit: 2b74710
buildURL: Build Status, Sponge
status: failed
gguuss commentedon Apr 27, 2020
I'm considering disabling the tests that are multithreaded as they seem to be causing issues with buildcop.
tmatsuo commentedon May 5, 2020
I think we haven't seen this failure for a while.
Maybe we can close this, and see how flaky it is now.