By design, the hammer is able to send a configurable fraction of duplicate entries to the add endpoint in order to test the storage implementations' handling of this case.
Due to the way this is currently implemented, this manifests as a "stutter" (i.e. A, B, C, C, D, ...).
While this is a valuable test to perform, it's primarily going to interact with deduplication happening in the FE "to-be-added" pool. It would be desirable for the hammer to be able to resubmit older entries from the tree, in order to test behaviour for duplicates which have already been persisted, too.
By design, the hammer is able to send a configurable fraction of duplicate entries to the
addendpoint in order to test the storage implementations' handling of this case.Due to the way this is currently implemented, this manifests as a "stutter" (i.e.
A,B,C,C,D, ...).While this is a valuable test to perform, it's primarily going to interact with deduplication happening in the FE "to-be-added" pool. It would be desirable for the hammer to be able to resubmit older entries from the tree, in order to test behaviour for duplicates which have already been persisted, too.