In my experience money is absolutely part of the reason why people quit. Not everyone lives in places or is in circumstances where finances don't matter that much.

> create a partitioned table for events with a unique constraint on the event id

infinite error loop

Isn't the manual sync mode the solution for blocking for classic queues (assumming mirroring)?

Experiencing this issue.

First incident occured after enabling Query Insights. Have turned off the feature, will see how it goes.

Edit: nope, didn't help

I believe the exact scenario you propose is not possible. It cannot happen simultaneously (so A broadcasting his tx - txA and B broadcasting his tx - txB at the same time).

However, B can broadcast txB after receiving txA (txB essentially needs to know txA in order to "use" it).

The way this works is txA essentially says "send 1BTC I received from some tx to B". txB says "send 1BTC I received from txA to C". So, when creating the txB, B needs txA in order to use it.

Keep in mind this has nothing to do with txA or txB being included in blocks. txB can use txA if txA is not yet confirmed (so not in a block), however txB can only be included in a block (so confirmed) if txA is already confirmed in a previous block, or if both transactions are in the same block (this is where the part of a miner "ordering" the transactions from some other replies comes in play).