In the runtime events consumer library, there's a code path that handles the case when an event content is read, but in the meantime was overwrote by the producer. In that case, it calls the the lost_events callback if it exists, but then continues parsing the event with whatever data overwritten in the ring buffer, yielding incorrect values.

This problem appeared when I used custom runtime events at a very high rate (700k/s). Indeed, at a low rate this code path is rarely taken.

The PR includes a reproduction test that spawns two domains, one emitting custom events at a high rate and one consuming them and checking that the associated value is expected (0). If it's different, it means that the event payload was overwrote with a new event block (the expected zero value would then contain a header or timestamp value parsed as an integer).

The proposed fix is the following: continue (jump over event parsing) for all code paths as long as the event dropped condition is met:

 /* Check the message we've read hasn't been overwritten by the writer */
 if (ring_head > cursor->current_positions[domain_num]) {
     ...
+    continue;
 }

@Engil @sadiqj