Race Condition in Adonisjs with Firestore

A race condition in AdonisJS when interacting with Google Cloud Firestore occurs when multiple concurrent requests read and write overlapping document state without adequate synchronization, leading to inconsistent outcomes. Firestore offers strong consistency for single-document reads, but write operations (set, update, delete) are atomic only at the document level. If your AdonisJS application implements multi-step workflows—such as read-modify-write or conditional updates—across multiple documents or relies on client-side counters, timing differences between requests can cause lost updates or invalid state transitions.

For example, consider an inventory endpoint in AdonisJS that reserves items by reading the current available count, checking business rules, and then decrementing the value. If two requests execute this sequence in parallel, both may read the same initial count, each pass the validation, and each write back a decremented value, resulting in an undercount. This pattern maps to common web application behaviors like booking systems or ticket sales, and it is not mitigated by Firestore’s single-document atomicity because the vulnerability spans logical steps across the application layer.

In AdonisJS, typical triggers include: controller methods that perform read-then-write without transactions or optimistic concurrency control; background jobs or queued tasks that process the same document simultaneously; and HTTP endpoints that rely on client-supplied values for critical fields without server-side revalidation. Firestore security rules can enforce data shape and authentication, but they do not serialize logical application workflows across requests. Therefore, the framework does not inherently prevent race conditions; developers must design concurrency-safe patterns using Firestore primitives such as transactions and batched writes.

Race conditions in this stack also intersect with other security checks middleBrick performs, such as Input Validation and Property Authorization. For instance, insufficient validation on numeric deltas or missing ownership checks can amplify the impact of concurrent manipulation, enabling privilege escalation or unauthorized inventory adjustments. The scanner tests unauthenticated attack surfaces, so improper exposure of write endpoints without concurrency safeguards will be flagged during an assessment.

To remediate race conditions in AdonisJS with Firestore, use server-side transactions for read-modify-write sequences and leverage Firestore’s built-in atomic operations. Transactions ensure that a set of reads and writes either fully succeed or fully fail, preventing interleaved execution from other clients. Below are concrete, working examples aligned with typical AdonisJS project structures.

1. Transactional inventory decrement

Use a transaction to read and update a document atomically. This example assumes an items collection where each document has an available numeric field.

import { DateTime } from 'luxon'
import { Firestore } from '@google-cloud/firestore'
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

const firestore = new Firestore()

export default class InventoryController {
  public async reserve({ request, response }: HttpContextContract) {
    const itemId = request.param('id')
    const requested = request.input('quantity', 1)

    const itemRef = firestore.collection('items').doc(itemId)
    let transaction = firestore.transaction()

    try {
      const doc = await transaction.get(itemRef)
      if (!doc.exists) {
        return response.notFound({ error: 'Item not found' })
      }

      const available = doc.get('available') as number
      if (available < requested) {
        return response.badRequest({ error: 'Insufficient inventory' })
      }

      transaction.update(itemRef, { available: available - requested })
      await transaction.commit()

      return response.ok({ success: true, available: available - requested })
    } catch (error) {
      transaction.rollback()
      return response.internalServerError({ error: 'Transaction failed' })
    }
  }
}

2. Atomic increment with server-side numeric operations

When simple increments or decrements are sufficient, use Firestore’s server-side numeric transforms to avoid read-before-write patterns entirely.

import { Firestore } from '@google-cloud/firestore'

const firestore = new Firestore()
const itemRef = firestore.collection('items').doc('abc123')

// Atomically decrement available by 1 without reading first
await itemRef.update({
  available: FieldValue.increment(-1)
})

// You can still read afterwards if needed
const snap = await itemRef.get()
console.log('Remaining:', snap.get('available'))

3. Conditional updates with update-time assertions

For cases where a transaction is too heavy, use update with a precondition value (e.g., version number or timestamp) to ensure the document has not changed since it was last read.

import { Firestore } from '@google-cloud/firestore'

const firestore = new Firestore()
const itemRef = firestore.collection('items').doc('abc123')

const snapshot = await itemRef.get()
const currentVersion = snapshot.get('version')

// Attempt update only if version matches
await itemRef.update({
  available: 42,
  version: currentVersion + 1
}, { lastUpdateTime: snapshot.updateTime })
// Note: Firestore does not support lastUpdateTime precondition directly in JS SDK;
// use transactions or Firestore preconditions via REST or Admin SDK for strict enforcement.

In AdonisJS, wrap these operations in services or commands, and ensure that endpoints requiring strong consistency explicitly use transactions. Avoid relying on client-supplied state for critical invariants, and validate all inputs server-side to reduce manipulation surfaces. These patterns mitigate race conditions while aligning with Firestore’s strengths.