-
Notifications
You must be signed in to change notification settings - Fork 325
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
Conversation
There was a problem hiding this 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. :-)
359b5ae
to
3cf6ab4
Compare
deleteUser_ (Just tok) (Just uid) spar | ||
!!! const 404 === statusCode -- https://tools.ietf.org/html/rfc7644#section-3.6 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 threadDelay
s slowing down our tests and making things flaky
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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!)
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?