Is there any reason RepServer would resend a transaction already applied?

I'm seeing RepServer attempting to insert records it already inserted. The primary table has a simple unique identity field, which follows through with the replication definition "primary key" for the table on the primary RepServer (in our east coast datacenter). The secondary RepServer (in our midwest datacenter) subscribes and populates the secondary table with no problems, usually. We've recently been using the secondary side for testing our next web site release. Inevitably while they test, we've been seeing the DSI thread go down due to duplicate key errors.

Naturally, we assumed their testing must be entering data into this table from the secondary side. They, of course, insist they aren't. Looking more closely, I noticed our field indicating when the record was last updated was the same on both sides. They obviously didn't.

CREATE TABLE DDL includes:

UID numeric(12) identity not null
constraint uid_pk primary key (UID)

UID DATA secondary insert time primary insert time

7047 0AB7 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7048 BAE3 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7049 0AA9 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7050 2DY0 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7051 0AQ4 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7052 0AN1 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7053 0AR2 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7054 6MB9 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7055 0AG6 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7056 0AL5 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7057 6MH6 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

7058 QFG4 Jan 27 2015 3:45PM Jan 27 2015 3:45PM

The secondary RepServer begins with the usual "A grouped transaction of 20 individual transactions has failed in database ..." "... DSI received data server error #2601 which is mapped to STOP_REPLICATION." Yesterday, we happen to see 12 contiguous records already inserted on the secondary side. Since we had to resynchronize our databases anyway due to testing, I can just skip these transactions. After all, the record appears to already be there. So far, this only happens while the secondary ASE has active connections testing (no deadlocks, nor any error messages in either ASE logs, nor messages in the primary RepServer errorlog).

Any ideas? So far, we never see this on the days there isn't random testing going on in the secondary ASE.