Fanout on root fails when doing concurrent transaction on unrelated property - firebase

Question

The code below shows the minimum example where we see the bug. As you can see, the fanout test/channels/sameKey/chats/${key} while the transaction updates test/user_phone_numbers/${key}.
If I'm understanding transaction and update correctly, these two don't overlap so it should be safe to run concurrently. However, as soon as two concurrent requests come in, Firebug errors out with [Error: set].
'use strict';
const express = require('express');
const server = express();
const firebaseRootRef = new Firebase(process.env.FIREBASE_URL)
const random = max => Math.floor(Math.random() * max)
let key = 0
const nextKey = () => ++key % 2
const fanout = key => {
const fanout = {
[`test/channels/sameKey/chats/${key}`]: random(1000)
}
return firebaseComponent.update(firebaseRootRef, fanout)
}
const transaction1 = key => firebaseRootRef.child('test/user_phone_numbers/' + key)
.transaction(_userId => !_userId ? random(100000) : undefined)
server.get('/', (req, res) =>
transaction1(nextKey())
.then(() => fanout(key))
.then(() => res.send(200))
.catch(e => {console.log(e); res.send(501)})
)
server.listen(3001, function () {
console.log('incoming.controller listening on port 3001!');
});
The apache benchmark command to replicate:
ab -n 1000 -c 2 -r http://localhost:3001/

Answer 1

This isn't a bug, it's working as intended. I ran into this several months back and here's the official response they gave me (emphasis mine).
The issue here are transactions in combination with update calls.
We'll abort any transactions at, below or above the path in any set or
update call. So while the transaction is technically unaffected by
your update call at /venues/1, we still go ahead and cancel the
transaction. We know this is not optimal and we're looking into
improving this with a future release. One workaround is to defer the
update calls until the transactions have completed, or keep the
data in an entirely different subtree. The simplest workaround
might be to move all the writes in the update call into separate set
calls, which will not abort the transaction.