Re: racing risk in MultiTxn's serialize

No significant changes should ever be made to any transaction as it passes through the pipeline. The code you point out is the creation of the multi. The mutation is in the same block that created it and no references escape before the endVector call is made. I request again. Can you please stop

Re?? racing risk in MultiTxn's serialize

I found that  one observer's SyncRequestProcessor is appending one  MultiTxn's log, FinalRequestProcessor access MultiTxn's at the same time. maybe MultiTxn will be modified by FinalRequestProcessor  in the future. It already was when I modified zk server to be a tool dealing txn logs. ---

?????? racing risk in MultiTxn's serialize

I found that  one observer's SyncRequestProcessor is appending one  MultiTxn's log, FinalRequestProcessor access MultiTxn's at the same time. maybe MultiTxn will be modified by FinalRequestProcessor  in the future. It already was when I modified zk server to be a tool dealing txn logs.  -