Non-Atomic Operation Review Prompt

This prompt is for backend engineers and code reviewers who need to identify atomicity violations in compound operations before they merge into the main branch. The job-to-be-done is systematic detection of check-then-act races, read-modify-write gaps, and multi-step operations that lack transactional protection. The ideal user has access to a code diff, understands the language's concurrency model, and needs structured findings that map to specific synchronization primitives—not generic warnings about thread safety.

Use this prompt when reviewing code that spans multiple statements where correctness depends on all-or-nothing execution. Concrete triggers include: database updates preceded by a separate read to check current state, increment operations that read then write without atomic primitives, file system operations that check existence before creating, and any sequence where an external actor could mutate state between steps. The prompt requires [CODE_DIFF] as input and produces an atomicity violation report with violation type, location, risk severity, and suggested synchronization primitives. It is designed to work with diffs from any language but produces the most precise guidance when [LANGUAGE] is specified to select the correct concurrency primitives.

Do not use this prompt for single-statement operations, code that already uses appropriate atomic primitives, or pure functions with no shared state. It is not a general code quality reviewer—it focuses narrowly on atomicity boundaries. For broader concurrency review, pair it with the Thread Safety Review Prompt or Deadlock Potential Analysis Prompt. For production use, always route high-severity findings to human review before accepting fix suggestions, and validate the prompt's output against known atomicity bug patterns in your codebase to calibrate false positive tolerance.

The following prompt template is designed to be dropped into a code review pipeline, CI/CD check, or manual review workflow. It expects a code diff or function body as input and produces a structured atomicity violation report. Every placeholder is enclosed in square brackets so you can wire in your own diff source, language context, risk tolerance, and output schema without modifying the core instruction logic.

textCopy
You are a systems code reviewer specializing in concurrency safety and atomicity guarantees. Your task is to analyze the provided code for non-atomic operations that should be atomic.

## INPUT
[CODE_DIFF_OR_FUNCTION_BODY]

## CONTEXT
- Language: [LANGUAGE]
- Framework/ORM: [FRAMEWORK]
- Transaction model: [TRANSACTION_MODEL] (e.g., database transactions, software transactional memory, compare-and-swap loops)
- Concurrency model: [CONCURRENCY_MODEL] (e.g., multi-threaded, async event loop, goroutines, actors)
- Risk tolerance: [RISK_LEVEL] (low/medium/high; high means flag even unlikely interleavings)

## REVIEW INSTRUCTIONS
1. Identify every compound operation that reads state and then acts on that state without atomic protection.
2. For each finding, classify the pattern:
   - CHECK-THEN-ACT: A condition is checked and then an action is taken based on that condition, with a window where the condition can change.
   - READ-MODIFY-WRITE: A value is read, modified, and written back without synchronization, allowing lost updates.
   - MULTI-STEP WITHOUT TRANSACTION: Multiple operations that must succeed or fail together but lack a transactional boundary.
   - NON-ATOMIC COUNTER/ACCUMULATOR: Increment, decrement, or accumulation operations that are not atomic.
3. For each finding, provide:
   - The exact line range where the violation occurs.
   - A description of the interleaving that would cause incorrect behavior.
   - The data integrity risk (corruption, lost update, duplicate, inconsistent read).
   - A severity rating (CRITICAL, HIGH, MEDIUM, LOW) based on [RISK_LEVEL].
   - A suggested synchronization primitive or refactoring (e.g., database transaction, mutex, atomic operation, compare-and-swap, optimistic locking with version field, SELECT FOR UPDATE).
4. If no violations are found, explicitly state that and explain why the operations appear safe under the given concurrency model.
5. Do not flag operations that are already protected by an enclosing transaction, mutex, or atomic primitive visible in the provided code.

## OUTPUT FORMAT
Return a JSON object with this exact schema:
{
  "review_summary": {
    "total_findings": <integer>,
    "critical_count": <integer>,
    "high_count": <integer>,
    "medium_count": <integer>,
    "low_count": <integer>,
    "assessment": "<one sentence overall assessment>"
  },
  "findings": [
    {
      "id": "<ATOM-001, sequential>",
      "pattern": "<CHECK-THEN-ACT | READ-MODIFY-WRITE | MULTI-STEP_WITHOUT_TRANSACTION | NON-ATOMIC_COUNTER>",
      "severity": "<CRITICAL | HIGH | MEDIUM | LOW>",
      "line_range": "<start_line-end_line>",
      "description": "<what the code does and why it's non-atomic>",
      "interleaving_scenario": "<step-by-step description of a problematic concurrent execution>",
      "data_integrity_risk": "<corruption | lost_update | duplicate | inconsistent_read>",
      "suggested_fix": "<concrete synchronization primitive or refactoring approach>",
      "code_sketch": "<optional brief pseudocode or pattern name for the fix>"
    }
  ],
  "safe_operations_note": "<explanation if no findings, otherwise null>"
}

## CONSTRAINTS
- Do not hallucinate synchronization primitives that don't exist in [LANGUAGE].
- If the code uses an ORM, consider its built-in optimistic locking or transaction support before suggesting raw SQL.
- For MEDIUM and LOW severity findings, note whether the risk is theoretical or practically exploitable under typical load.
- If [RISK_LEVEL] is "high," flag even single-instruction windows where a context switch could cause inconsistency.

To adapt this template, replace the square-bracket placeholders with values from your review context. For CI/CD integration, wire [CODE_DIFF_OR_FUNCTION_BODY] to the output of git diff or a pull request API. Set [RISK_LEVEL] to "high" for payment, inventory, or auth code paths; use "medium" for most backend services; reserve "low" for read-heavy or idempotent operations. The output schema is designed to be machine-readable so you can post findings directly to review tools, block merges on CRITICAL findings, or aggregate severity counts into dashboards. Always validate the JSON output against the schema before surfacing results to developers—malformed JSON or missing required fields should trigger a retry or fallback to a simpler text-only prompt.

Integrating the Non-Atomic Operation Review Prompt into a production workflow requires treating it as a deterministic analysis step within a larger pipeline, not a standalone chat interaction. The prompt should be triggered automatically on pull request creation or code push, receiving a structured diff as input. The application layer is responsible for chunking large diffs into logical units (e.g., by file or function) to stay within context limits and for enriching the prompt with language-specific context, such as the primary concurrency primitives and transaction models in use. The model's output must be parsed as structured JSON and validated against a strict schema before any findings are surfaced to a developer, ensuring that only well-formed, actionable reports enter the review queue.

A robust implementation requires a validation and retry layer. After receiving the model's JSON response, validate that every finding includes the required fields: file_path, line_range, atomicity_violation_type (e.g., 'check-then-act', 'read-modify-write'), description, and suggested_primitive. If validation fails, implement a retry loop with a maximum of two attempts, feeding the validation error back into the model's context to guide self-correction. For high-risk repositories, route all validated findings to a human review queue rather than posting them directly as inline comments. Log every prompt version, input diff hash, raw model output, and validation result to an observability platform. This audit trail is critical for tuning the prompt, diagnosing false positives, and defending review decisions. Choose a model with strong code reasoning capabilities and low latency, as this check sits on the critical path for developer feedback; a fast instructor-tuned model is often a better fit than a largest frontier model if it meets accuracy thresholds on your eval set.

To prevent alert fatigue, implement a severity filter in the application harness. Only surface findings classified as HIGH or CRITICAL as blocking review comments, while routing LOW severity notes to a non-blocking informational report. Before enabling the check as a required status for merges, run it silently against a historical dataset of known atomicity bugs and clean code to calibrate precision and recall. The next step is to integrate the prompt's output with your existing static analysis dashboard, correlating atomicity findings with test gap reports to prioritize where new concurrency stress tests are needed most.