

Unprocessed RU count shows how many units were received by replica but haven never been started to process.
It can happen in the following case: 
 - replication batch is 1000, source sends data to replica by batches, every batch consist of 1000 RUs
 - replica starts processing of batch, RU by RU from the first one
 - replica gets error while processing RU N 101
 - replica increments 'total ru count' per 100 
 - replica increments 'failed ru count' per 1 
 - replica increments 'unprocessed ru count' per 899 

So I think there everything is ok with 'unprocessed unit count’, just maybe it needs to be renamed.

Yes, I think it is good idea to count only the first time the RU was failed. But it is also useful to have total failures count.  May be we need more properties here.
For example we can have the following properties:
  - Currently Failed RU Count – actually, it can be 0 or 1 
  - Total Failed RU Count – the same as now
  - Discarded Statement Count  - how many statements were discarded in validation trigger (we already have it)
  - Skipped Statement Count – how many statements were skipped(not implemented)
  - Skipped RU Count – how many RU were skipped(not implemented)

So there is a problem if 'currently failed RU count' is 1. It means that we are trying to reprocess the same RU and fail every time.

To skip statements we need new type of trigger on replica, which will be executed after failed statements.
This trigger should decide either to fail the replication or to skip this statement or the whole RU.

Currently we don’t have any mechanism to skip RU from replication queue. Only discard in validation trigger.

We told before about rejected queue.
