Currently when records are loaded to the engine, it's not obviously clear wether they come from actions that just happen or are one already save and now are being restored.
Theoretically it can be assumed by stamp, but:
It's not certain how old stamp should be to be assumed as restore one.
It's not reliable approach as store records, could ones that waited on a client-side for a day-long
Use case are email notifications as sent in server side (master) process, which should not be send in case of restored records. Current way of dealing with it, is configuration of two-step triggers, where we require at least a tick-gap between them to approve change as a trigger for event.
The valid solution would be probably to mark event injections batches as either store or restore kinds. Those kind of batches never happen as mixed, and we could in our listeners detect wether state change was triggered by store or restore batch.
Currently when records are loaded to the engine, it's not obviously clear wether they come from actions that just happen or are one already save and now are being restored.
Theoretically it can be assumed by
stamp, but:Use case are email notifications as sent in server side (master) process, which should not be send in case of restored records. Current way of dealing with it, is configuration of two-step triggers, where we require at least a tick-gap between them to approve change as a trigger for event.
The valid solution would be probably to mark event injections batches as either store or restore kinds. Those kind of batches never happen as mixed, and we could in our listeners detect wether state change was triggered by store or restore batch.