When a reader, or several readers, has been unreachable for a while, but active, and this reader becomes reachable, the processor will get a large amount of events to process. The way these are currently processed may not be very efficient. Maybe the processor should be changed to process events in a more batched way, in a single database transaction, when there's a lot of events in the queue. Also, it should then only notify the changed state only once.
Another consideration is if old information is still useful: corrections may have already been performed in the meantime. Maybe the UI should propose to the user that they review their corrections if the new state causes there to be extra laps in the past? Or could we make it disregard extra laps in the past?
When a reader, or several readers, has been unreachable for a while, but active, and this reader becomes reachable, the processor will get a large amount of events to process. The way these are currently processed may not be very efficient. Maybe the processor should be changed to process events in a more batched way, in a single database transaction, when there's a lot of events in the queue. Also, it should then only notify the changed state only once.
Another consideration is if old information is still useful: corrections may have already been performed in the meantime. Maybe the UI should propose to the user that they review their corrections if the new state causes there to be extra laps in the past? Or could we make it disregard extra laps in the past?