I didn't realize anyone had added to the WaitCriterion interface. That
explains why we don't have constant failures caused by this! Unfortunately,
that means I didn't find a potential cause of flakiness in one of my tests.
On Thu, Apr 11, 2019 at 12:20 PM Dan Smith <dsm...@pivotal.io> wrote:
> WaitCriterion extends ThrowingRunnable. So this pattern should still work
> as WaitCriterion did before. But just using an assertion inside of a lambda
> is the better option.
>
> -Dan
>
> On Thu, Apr 11, 2019 at 12:02 PM Kirk Lund <kl...@apache.org> wrote:
>
> > Just a quick heads up... I'm seeing an Awaitility usage pattern that is
> > broken and does nothing. Specifically, it's any uses of dunit
> WaitCriterion
> > with untilAsserted:
> >
> > GeodeAwaitility.*await().untilAsserted(new WaitCriterion*() {
> >
> > @Override
> > public boolean done() {
> > return region.isDestroyed();
> > }
> >
> > @Override
> > public String description() {
> > return "Region was not destroyed : " + region.isDestroyed();
> > }
> > });
> >
> > The above is broken. It will not await anything. Invoking "new
> > WaitCriterion()" will not throw anything so untilAsserted returns
> > immediately. This may cause some flaky tests to be flakier because we're
> no
> > longer waiting for the WaitCriterion done to be true.
> >
> > To fix this, just change it to use await().until with a lambda containing
> > the contents of done():
> >
> > GeodeAwaitility.*await().until(() -> *region.isDestroyed());
> >
>
