Thanks for a bug report. This is a timing issue, which works most of the times fine, but not always. I can reproduce it with something like:

   $ for i in {1..100}; do ./test-cal-client-get-revision; done

where it fails only couple times. A workaround in the code might be to add a sleep before the e_client_get_backend_property_sync() is called, thus D-Bus has enough time to deliver the notification about the property change. 10 ms had been enough here.

The thing is, the property is a D-Bus property, which means it's not updated on the client side immediately. I guess I can add some workaround for it into the code, like the aforementioned sleep, but I'm afraid it'll be ugly.

A bit better command, which also shows how many tests passed successfully:

   $ export _GOOD=0 && for i in {1..100}; do .test-cal-client-get-revision && \
         export _GOOD=$((_GOOD+1)); done; echo "good:${_GOOD}"

There's a very similar test for EBookClient, which doesn't fail, due to having more operations being done before reading the revision number back (it adds a contact, verifies it's added and immediately removes it, then it reads the revision). The ECalClient test only added a component and read the revision back, which didn't give enough time to the D-Bus to deliver the property change. I fixed it upstream [1] (for 3.31.3+ and 3.30.3+) by adding the component removal to the code, similarly as the book test works.

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/5eaebbe5c

*** Bug 1712327 has been marked as a duplicate of this bug. ***

Hrm, this is very tricky. Even when I flush the pending notifications over D-bus on the server side, the client side still doesn't receive them always. I ended with a workaround added to the test, which will wait half of a second (to give the D-Bus and the client side to receive the property change), when the property didn't change yet. This is logged in the test output with this text: "D-Bus property 'revision' change not received, trying to wait a bit".

I split the change upstream to [1] and [2], committed for 3.33.3+ and 3.32.3+.

We do not have a RHEL8 bug for this, do we? The version in RHEL8 is also affected.

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/760002735da1
[2] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/1be2a36737b8

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2018