You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3173

Built from 1d28d6f

Thank you! Small question, why do we need to attempt many times until we get the value that we want?

Isn't there a way to make it more deterministic?

Thank you! Small question, why do we need to attempt many times until we get the value that we want?

Isn't there a way to make it more deterministic?

The nullifier log works like a capped queue with a maximum size of 4 epochs. When a new message arrives in epoch 5, the log needs to both remove the oldest message (from epoch 1) and add the new message. The flaky test occurs because we're checking the log length immediately after this operation - sometimes we catch it when it's only removed the old message (length = 3) but hasn't yet added the new one (should be 4). Instead of using a fixed wait time, we can make the test more reliable by actively waiting until the log reaches its expected length of 4, confirming both the removal of the old message and addition of the new one is complete. or we can do like as you suggest more deterministict, wait little longer like ( 10000 milies ). that also help get rid this flakiness. it's kind of fixed waiting but yeah it's more straight forword. whatever you suggest ? 🤟🏻

The nullifier log works like a capped queue with a maximum size of 4 epochs. When a new message arrives in epoch 5, the log needs to both remove the oldest message (from epoch 1) and add the new message. The flaky test occurs because we're checking the log length immediately after this operation - sometimes we catch it when it's only removed the old message (length = 3) but hasn't yet added the new one (should be 4)

Got it, thank you! Makes sense, yes it's better as you did then! Better to catch earlier and don't wait more time than needed.

Last question then. If the queue has size 4 and a message is removed and the new one is added - isn't it possible for the queue to be size 4 and pass the test even before the message was even sent?

In other words, how do we now that this check is not done before we remove the message and pass without having done any operation?

The nullifier log works like a capped queue with a maximum size of 4 epochs. When a new message arrives in epoch 5, the log needs to both remove the oldest message (from epoch 1) and add the new message. The flaky test occurs because we're checking the log length immediately after this operation - sometimes we catch it when it's only removed the old message (length = 3) but hasn't yet added the new one (should be 4)

Got it, thank you! Makes sense, yes it's better as you did then! Better to catch earlier and don't wait more time than needed.

Last question then. If the queue has size 4 and a message is removed and the new one is added - isn't it possible for the queue to be size 4 and pass the test even before the message was even sent?

In other words, how do we now that this check is not done before we remove the message and pass without having done any operation?

Excellent observation! I agree – since the pre-check has already done in epoch 4, we just need to focus on the post-check for the subsequent epoch.