Skip to content
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

Adjust flaky test for user deletion in SCIM #667

Merged
merged 1 commit into from
Mar 20, 2019

Conversation

ChrisPenner
Copy link
Contributor

@ChrisPenner ChrisPenner commented Mar 19, 2019

Deletion calls out to brig asyncronously (hence the 204) so this test is very flakey and is breaking on CI; there's no guarantee that the user is properly deleted by the second time we call. We could add some threadDelay; but that's just slowing down our test suite and hiding the flakiness.

I prefer instead to just leave double-deletion undefined in the tests; in practice it will 404 unless you call it twice very quickly in which case it will 204 twice which I think is totally fine.

Thoughts @fisx?

@ChrisPenner ChrisPenner changed the title Checking for 404 is flaky; depends on deletion succeeding Adjust flaky test for user deletion in SCIM Mar 19, 2019
Copy link
Contributor

@fisx fisx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as discussed: would be nice to have a more tolerant test ("we expect either 204 or 404"), or at least a comment to keep me from adding this again in the future. :-)

@ChrisPenner ChrisPenner force-pushed the cp/fix-deletion-tests branch from 359b5ae to 3cf6ab4 Compare March 20, 2019 10:43
@ChrisPenner ChrisPenner merged commit d4bd18c into develop Mar 20, 2019
@ChrisPenner ChrisPenner deleted the cp/fix-deletion-tests branch March 20, 2019 12:14
deleteUser_ (Just tok) (Just uid) spar
!!! const 404 === statusCode -- https://tools.ietf.org/html/rfc7644#section-3.6
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should instead wait until a 404 actually happens... otherwise how do we ensure that users actually get deleted?

Copy link
Contributor Author

@ChrisPenner ChrisPenner Mar 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrmm this is a good point; do you have a suggestion of how to do this cleanly? I want to avoid having a bunch of threadDelays slowing down our tests and making things flaky

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could use the same retry trick we use elsewhere. we just keep deleting until we get a 404.

grep for retry or Control.Retry.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(should have thought of that when you asked me, sorry!)

@fisx fisx mentioned this pull request Mar 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants