test: fix wait_until_change_detection_event_completes for change detection < 1s#2971
Conversation
…< 1s in case the change detection happens within one tick __change_event_status might return CHANGE_EVENT_END right after the previous tick returned an empty string "" also reduce ticks in docker container to .1 s (we can expect an up-to-date bash inside the container)
georglauterbach
requested review from
casperklein,
georglauterbach and
polarathene
and removed request for
georglauterbach
georglauterbach
left a comment
georglauterbach
left a comment
There was a problem hiding this comment.
LGTM 👍🏼 Thank you very much for taking the time!
| [[ $(__change_event_status) == "${CHANGE_EVENT_START}" ]] \ | ||
| || [[ $(__change_event_status) == "${CHANGE_EVENT_END}" ]] |
There was a problem hiding this comment.
@polarathene could you please double-check this for me? I think it's fine but not 100% sure whether the logic checks out - it should though, just making sure here.
There was a problem hiding this comment.
CHANGE_EVENT_END implies the changedetector service is no longer processing the event. This would risk causing false positives.
The correct approach to resolve the bug is described in my comment on a related issue.
I should have time to look into resolving this myself today or tomorrow.
I wasn't aware that sleep could use non-integer values for sub-second delays. That alone would probably be enough in most cases. If not adding in the counting mechanism should do the trick, possibly also adding a way to increase the polling window of the change detector service itself (for the purpose of tests at least).
There was a problem hiding this comment.
Sound's good. @polarathene it's not the polling interval of the changedetector that's interfering here, it's the time to process a change event. if it takes less time to process the event than the interval that checks it the changedetector has started processing the event, in the current code this causes the event status to be CHANGE_EVENT_END before it ever returned CHANGE_EVENT_START.
However i think the counting option would be a better solution for sure.
georglauterbach
changed the title
wait_until_change_detection_event_completes for change detection < 1s
3 participants
Description
in case the change detection happens within one tick __change_event_status might return CHANGE_EVENT_END right after the previous tick returned an empty string ""
also reduce ticks in docker container to .1 s (we can expect an up-to-date bash inside the container)
on our CI systems and DEV machines the change detection happen well bellow 1s:
which lead to tests failing most of the times the as one output of the
tail -1was `` followed by the next output beingCompleted handling of detected changeand the following never being true within the timeout:Output of failed tests:
Type of change
Checklist:
docs/)Info @wt-io-it
MAINTAINER EDIT (by @georglauterbach): Fixes #2966