Error: 10 ABORTED: Too much contention on these documents. Please try again

Question

What does this error mean?

Especially, what do they mean by : Please try again

Does it mean that the transaction failed I have to re-run the

Answer 1

I have implemented a simple back-off solution to share : maintain a global variable that assigns a different "retry slot" to each failed connection. For example if 5 connections came at the same time and 4 of them got a contention error, each would get a delay of 500ms, 1000ms, 1500ms, 2000ms until trying again, for example. So it could potentially all resolved at the same time without any more contention.

My transaction is a response of calling Firebase Functions. Each Functions computer instance could have a global variable nextRetrySlot that is preserved until it is shut down. So if error.code === 10 is caught for contention issue, the delay time can be (nextRetrySlot + 1) * 500 then you could for example nextRetrySlot = (nextRetrySlot + 1) % 10 so next connections get a different time round-robin in 500ms ~ 5000ms range.

Below are some benchmarks :

My situation is that I would like each new Firebase Auth registration to get a much shorter ID derived from unique Firebase UID, thus it has risk of collision.

My solution is simply to check all registered short ID and if the query returns something, just generate an another one until it is not. Then we register this new short ID to the database. So the algorithm cannot rely on only Firebase UID, but it is able to "move to the next one" in a deterministic way. (not just random again).

This is my transaction, it first read a database of all used short ID then write a new one atomically, to prevent an extremely unlikely event that 2 new registers came at the same time, with a different Firebase UID that derived into the same short ID, and both see that the short ID is vacant at the same time.

I run a test that intentionally register 20 different Firebase UIDs which all derived into the same short ID. (extremely unlikely situation) All that runs in burst at the same time. First I tried using the same delay on next retry, so I expect it to clash with each other again and again while slowly resolving some connections.

• Same 500ms delay on retry : 45000ms ~ 60000ms
• Same 1000ms delay on retry : 30000ms ~ 49000ms
• Same 1500ms delay on retry : 43000ms ~ 49000ms

Then with distributed delay time in slots :

• 500ms * 5 slots on retry : 20000ms ~ 31000ms
• 500ms * 10 slots on retry : 22000ms ~ 23000ms
• 500ms * 20 slots on retry : 19000ms ~ 20000ms
• 1000ms * 5 slots on retry : ~29000ms
• 1000ms * 10 slots on retry : ~25000ms
• 1000ms * 20 slots on retry : ~26000ms

Confirming that different delay time definitely helps.