Title: #947: tests: fix race conditions in integration tests
First of all:
- I understand importance of "green" CI;
- those patches make CI "green".
So thank you for putting an effort in attempt to resolve this issue (that lasts quite long
You are right that the sleep is suppose to eliminated race condition
between touching the files and triggering inotify callback so it has to stay.
I see this as a bug in the SSSD (libnss_files.so doesn't have such an issue).
And I think hiding this bug in a test is not the best way to deal with it.
Probably I am wrong and this behavior of SSSD:files_provider can be justified.
But I am not sure if PR comments is proper place to do such justification.
From my point of view it would be preferable to:
1) mark parts of the test that fail due to described race as "expected to fail"
(to make CI usable)
2) open issue against files_provider, triage it properly
3) depending on the results of (2) either wait for fix or allow extended timeout in the
test (this patch)
Maybe this is way too pedantic. Maybe comments that you added to the test code, explaining
that test is only intended to check state *after* inotify callback run, are "good
I would really like to listen opinion of other maintainer...
`poll_canary` has no meaning as we currently block when refreshing
the cache. We can either remove it or report a bug against sssd that it behaves
I agree. This is another known issue with this test. I would await @jhrozek response
But probably you are right and this can be a subject of different PR.
1) Given your [nice
I am convinced
`INTERACTIVE_TIMEOUT` should be greater than `ENUMERATION_TIMEOUT + delay`. Recent
patchset misses this.
2) I am afraid I can't ack change of timeout meaning of which I do not understand (I
mean `INTERACTIVE_TIMEOUT/2`). But of course I can investigate it.
Based on the above, I would like other maintainers to provide their opinion.
See the full comment at https://github.com/SSSD/sssd/pull/947#issuecomment-561251947