Race Condition in Chi with Dynamodb

A race condition in a Chi application that uses Amazon DynamoDB typically occurs when multiple concurrent requests read and write the same item without sufficient synchronization, leading to lost updates or inconsistent state. In Chi, a common pattern is to read an item, compute a new value based on the current state, and then write it back. If two requests perform this read-compute-write cycle in parallel, the second write can overwrite the first, violating linearizability and causing data corruption or logic errors.

DynamoDB itself does not provide row-level locks for conditional updates across read and write phases unless you use conditional writes correctly. In Chi, handlers are often asynchronous and may be invoked concurrently for the same resource (e.g., updating an inventory count or a financial balance). An example scenario: an endpoint POST /accounts/{id}/withdraw reads an account balance, checks if sufficient funds exist, and then writes the new balance. A race condition arises when two withdrawals happen concurrently; both may read the same balance, both see sufficient funds, and both write a new balance, resulting in a negative balance or double-spend.

This becomes a security and integrity issue because the unauthenticated attack surface tested by middleBrick can expose endpoints that perform such non-atomic read-modify-write flows. Without atomic conditional updates, an attacker could induce or exploit timing variations to manipulate state, which may be reflected in findings related to BOLA/IDOR or Business Logic flaws in the scan results. Even with authenticated access, race conditions can lead to privilege escalation or data exposure when invariants are violated.

DynamoDB offers conditional writes via the ConditionExpression parameter, which ensures that an update only succeeds if the item matches expected attribute values. In Chi, you should perform updates in a single operation rather than separate read and write steps. For example, instead of reading an item to compute a new value, use an UpdateItem with an expression that atomically increments a counter or validates state before writing. This eliminates the window between read and write where race conditions can occur.

When integrating with DynamoDB, always prefer strongly consistent reads for critical checks if you must read before write, but strongly prefer atomic updates. Additionally, design your data model to avoid hotspots and ensure that conditional expressions are specific and include attribute existence checks to avoid unexpected outcomes. middleBrick’s checks for BFLA/Privilege Escalation and Property Authorization can help identify endpoints where unsafe read-modify-write patterns exist, and its Output scanning can detect whether responses inadvertently expose sensitive state that should be protected.

To remediate race conditions in Chi with DynamoDB, refactor your handlers to use atomic conditional updates. Below are concrete code examples demonstrating safe patterns.

Example 1: Atomic counter increment with condition

Instead of reading an item, incrementing in application code, and writing back, use an UpdateItem with ADD for numeric fields and a ConditionExpression to enforce invariants.

import chiselapi._
import software.amazon.awssdk.services.dynamodb.DynamoDbClient
import software.amazon.awssdk.services.dynamodb.model._

val ddb = DynamoDbClient.create()

def safeIncrement(accountId: String, amount: Int): Unit = {
  val request = UpdateItemRequest.builder()
    .tableName("Accounts")
    .key(Map("id" -> AttributeValue.builder().s(accountId).build()).asJava)
    .updateExpression("SET balance = balance + :inc")
    .conditionExpression("balance >= :min")
    .expressionAttributeValues(Map(
      ":inc" -> AttributeValue.builder().n(amount.toString).build(),
      ":min" -> AttributeValue.builder().n("0").build()
    ).asJava)
    .build()

  ddb.updateItem(request) // Throws ConditionalCheckFailedException if condition fails
}

Example 2: Deduplicate or set state with condition

When setting a state that must not be overwritten, use a condition that checks attribute existence or a specific value.

import software.amazon.awssdk.services.dynamodb.model._

def markOrderAsShipped(orderId: String): Unit = {
  val request = UpdateItemRequest.builder()
    .tableName("Orders")
    .key(Map("order_id" -> AttributeValue.builder().s(orderId).build()).asJava)
    .updateExpression("SET #status = :shipped, updated_at = :now")
    .conditionExpression("attribute_not_exists(#status) OR #status = :pending")
    .expressionAttributeNames(Map("#status" -> "status").asJava)
    .expressionAttributeValues(Map(
      ":shipped" -> AttributeValue.builder().s("SHIPPED").build(),
      ":pending" -> AttributeValue.builder().s("PENDING").build(),
      ":now" -> AttributeValue.builder().n(java.lang.String.valueOf(System.currentTimeMillis())).build()
    ).asJava)
    .build()

  ddb.updateItem(request)
}

Example 3: Using Chi routes with DynamoDB updates

In a Chi route, wrap the update in an endpoint that returns appropriate HTTP status on condition failure.

import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.implicits._

def withdrawRoute(ddb: DynamoDbClient): HttpRoutes[IO] = HttpRoutes.of[IO] {
  case req @ POST -> Root / "accounts" / accountId / "withdraw" =>
    val amount = req.as[WithdrawRequest].fold(_ => 0, _.amount)
    val updateReq = UpdateItemRequest.builder()
      .tableName("Accounts")
      .key(Map("id" -> AttributeValue.builder().s(accountId).build()).asJava)
      .updateExpression("SET balance = balance - :amt")
      .conditionExpression("balance >= :amt")
      .expressionAttributeValues(Map(
        ":amt" -> AttributeValue.builder().n(amount.toString).build(),
        ":zero" -> AttributeValue.builder().n("0").build()
      ).asJava)
      .build()

    IO.fromEither(ddb.updateItem(updateReq).attempt.map {
      case Right(_) => Ok()
      case Left _: ConditionalCheckFailedException => Conflict(s"Insufficient funds or invalid state for $accountId")
      case Left e => InternalServerError(s"Update failed: ${e.getMessage}")
    })
}

These patterns ensure that read and write operations are combined into a single atomic update, which DynamoDB executes as a single transaction. This eliminates the race window and aligns with secure coding practices. middleBrick’s Continuous Monitoring (Pro plan) can track such patterns over time, and its GitHub Action can enforce that endpoints do not contain unsafe read-before-write logic by scanning for anti-patterns in your codebase.