Deepthi Devaki Akkoorath

Also the NPE doesn't seems to affect this test because when this error happens, there are no subscription to correlate.

:sob: Will look into it. Probably then the topology is never updated :thinking:

Was quite difficult to reproduce it. But reproduced it after several runs https://github.com/camunda/zeebe/actions/runs/2783045847 From the logs it seems the topology is not updated correctly. ``` 08:48:44.386 [Broker-0-ZeebePartition-1] [Broker-0-zb-actors-1] INFO io.camunda.zeebe.broker.system...

Great point @oleschoenburg I suspected some thing like it, but the following test passed ``` @Test public void shouldExecuteInOrder() throws InterruptedException { // given final AtomicReference actorControl = new AtomicReference();...

> IMO `TopologyPartitionListenerImpl` could use a small rewrite to just use a `ConcurrentHashMap` instead of relying on `Int2IntHashMap` plus the actor scheduler. `TopologyPartitionListenerImpl` is only used by the `InterPartitionCommandSender`. I...

Then I will do that. Not yet sure if using its own actor or as @oleschoenburg said get rid of the actor and use a `ConcurrentHashMap` is better.

- `last_sync` if calculated from the snapshot_time, can be used to calculate the potential staleness. `last_sync` gives the exact time, while staleness is the difference between current time and what...

> It seemed to me that this would be only true if the materializer receives all updates and this might not be the case for remote updates, but this is...

In the proposed design `last_sync` and `last_sync_detail` are calculated from the snapshot_time of the transaction irrespective of the list of bound_objects being passed. So bound_objects as parameters is unnecessary. Do...

The materializer assumes that the operations it receives are in causal order. That assumption will be violated if we remove this check by the inter-dc module. It makes sense for...