A generated read-then-write lets both requests spend the same balance

Two handlers call getUser, both read the same balance, both pass the comparison, both subtract, and both write ^[1]. The post calls that a classic race condition and says one update may overwrite the other ^[2]. Firebase hides enough infrastructure that a small architectural mistake stays invisible until the application is under load ^[17].

Each of the four statements in the snippet is valid on its own. The snippet reads on its first statement and writes on its fourth, so a competing request has a two-statement window to land in ^[19]. A test that issues one request at a time keeps that window shut. Reviewers have nothing in the diff to point at, so the defect survives.

The remedy is a design choice, and the post treats it as one. Transactions are for writes that depend on current data; batched writes are for atomic write-only operations ^[3][4]. For thousands of users joining a queue at once it suggests separating event capture from processing with Cloud Tasks instead of pushing everything through database transactions ^[5]. The same judgement applies to ordering: do not assume equal sort values will always produce a stable order, and add a reliable secondary ordering when the application depends on it ^[6].

The item I would put in a checklist is the one about copying rules between products. Realtime Database permissions cascade through the data tree and Firestore rules do not work the same way, so a pattern moved from one to the other can produce serious security problems ^[10]. Paths in the two products look alike, and that resemblance is what a pattern matcher copies.

Which fields are permissions is something a generator can only guess at from the name. Of the five the post lists, createdAt and updatedAt are bookkeeping, and isAdmin, balance and plan decide what an account is entitled to ^[20]. It points at Firebase Authentication custom claims for server-controlled roles, and says Security Rules should be "treated as executable security code, tested and reviewed rather than accepted as generated boilerplate" ^[12][13]. The ownership test it offers is one line: allow write: if request.auth.uid == userId ^[8].

On retries the post is direct. "The code is syntactically fine. The problem is that the operation is not idempotent," it says of a welcome-email handler ^[15]. Payments, rewards, notifications, inventory updates and third-party API calls are the operations it names where a second execution matters ^[16].

The post does not say how often generated Firebase code carries these patterns; its case rests on the examples it walks through. In my view the ordering warning and the cross-product rule copy are the two items a syntax-clean generator will keep getting wrong, because both depend on facts that live outside the file it is editing.