How to check whether a query store is done processing events


For testing purposes we would like to check whether a query store is done processing events.

We could for example retrieve the max global index from the event store (by querying the database with JDBC) and check if all tracking tokens point to this index. But this solutions feels to “low level”.

Is there another (better) way in Axon to accompish this?


Hi Peter,

a typical async testing approach is to do the assertion as follows:

do an action
assert that, within x time, y is true.

Basically, you’ll have a “loop” to assert y. If it fails, that’s ok, as long as x time hasn’t passed yet. If y fails and the deadline passed, then the assertion propagates the failure.
This is some code we have used in the framework to test async behavior:

public static void assertWithin(int time, TimeUnit unit, Runnable assertion) {
    long now = System.currentTimeMillis();
    long deadline = now + unit.toMillis(time);
    do {
        try {
        } catch (AssertionError e) {
            if (now >= deadline) {
                throw e;
        now = System.currentTimeMillis();
    } while (true);

The idea is that you don’t care that the processor has processed an event. What you ultimately care about, is that the models have been updated correctly within a certain timeframe.

We do have some ideas about queries with position expectations. In that case, the command’s resultmessage would carry the token of the last event. You can use that token in a Query, which will not return you a response unless the projection is up to date until at least that token. We haven’t implemented this, yet, though.

Hope this helps.


Hi Allard,

Thanks for the quick reply!

So you basically propose to check the query model, instead of checking the underlying event store.

We thought of this too, but this would mean we have to implement a check for each query store.
And the expectation for each query store could be a “moving target” . We could for example check if a query store contains an expected number of entities. But this expectation can change as long as the query store changes.
Therefore, we thought a generic, low level solution would be a better approach.

Anyway, I 'll discuss with the team.