Add concurrency control

[simonforsberg]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -e

echo "=== Locking/version support ==="
rg -n -C2 '@Version|@Lock|LockModeType|version\b' \
  src/main/java/org/example/alfs/entities \
  src/main/java/org/example/alfs/repositories

echo
echo "=== Ticket mutation methods ==="
rg -n -C3 'updateTicketStatus|assignInvestigator|unassignInvestigator' \
  src/main/java/org/example/alfs/services/TicketService.java

Repository: ithsjava25/project-backend-alfs

Length of output: 106

---

🏁 Script executed:

#!/bin/bash
set -e

echo "=== Ticket entity structure ==="
fd 'Ticket\.java$' src/main/java/org/example/alfs/entities --type f | head -5 | xargs -I {} sh -c 'echo "File: {}"; cat -n "{}"'

echo
echo "=== TicketRepository ==="
fd 'TicketRepository\.java$' src/main/java/org/example/alfs/repositories --type f | head -5 | xargs -I {} sh -c 'echo "File: {}"; cat -n "{}"'

echo
echo "=== Full TicketService.updateTicketStatus method ==="
rg -n -A 20 'public.*updateTicketStatus' src/main/java/org/example/alfs/services/TicketService.java

echo
echo "=== Full TicketService.assignInvestigator method ==="
rg -n -A 20 'public.*assignInvestigator' src/main/java/org/example/alfs/services/TicketService.java

echo
echo "=== Full TicketService.unassignInvestigator method ==="
rg -n -A 20 'public.*unassignInvestigator' src/main/java/org/example/alfs/services/TicketService.java

Repository: ithsjava25/project-backend-alfs

Length of output: 8064

---

These ticket mutations are race-prone and need concurrency control.

All three mutation methods (updateTicketStatus, assignInvestigator, unassignInvestigator) perform read-check-write sequences on the same Ticket row without concurrency guards. Two concurrent requests can both pass precondition checks and then overwrite each other—last-write-wins. For example, two calls to assignInvestigator() can both observe ticket.getInvestigator() == null, both pass the guard at line 159, and then both attempt to save, with the second request overwriting the first.

The Ticket entity has no @Version field for optimistic locking, and TicketRepository exposes no locked query methods, so there is currently no mechanism to prevent these collisions.

Add optimistic locking (@Version on Ticket) or use pessimistic locking when fetching the row in these mutation flows.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/org/example/alfs/services/TicketService.java` around lines 108
- 129, The three mutation flows (updateTicketStatus, assignInvestigator,
unassignInvestigator) perform read-check-write on the same Ticket and are
race-prone; fix by adding concurrency control: either add an optimistic lock
field to the Ticket entity (a long/int field annotated with `@Version`) and let
JPA detect concurrent updates on ticketRepository.save, or change the repository
access in those methods to fetch the row with a pessimistic lock (e.g., a new
repository method or using EntityManager.find with
LockModeType.PESSIMISTIC_WRITE) so the precondition checks and the subsequent
save happen under a lock; update the code paths in updateTicketStatus,
assignInvestigator, and unassignInvestigator to use the chosen locking strategy
and handle OptimisticLockException / lock-related exceptions appropriately.

Originally posted by @coderabbitai[bot] in #12 (comment)

[coderabbitai]

🔗 Related PRs

#1 - Feature/entities [merged]
#2 - Feature/entity edit [closed]
#4 - Feature/repository [merged]
#6 - Feature/non editable ticket [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[simonforsberg]

src/main/java/org/example/alfs/services/TicketService.java (1)

108-129: ⚠️ Potential issue | 🔴 Critical

These lifecycle mutations are still last-write-wins.

@Transactional does not serialize these read-check-write paths. Two concurrent assignInvestigator() calls can both pass the null-assignee guard, and the later save overwrites the first; the same applies to status updates racing with assignment or unassignment. Please add optimistic locking on Ticket (@Version) or fetch the row with a write lock before relying on these guards.

Verification script

#!/bin/bash
set -e

ticket_file="$(fd 'Ticket\.java$' src/main/java --type f | head -n 1)"
repo_file="$(fd 'TicketRepository\.java$' src/main/java --type f | head -n 1)"

echo "=== Ticket entity locking markers ==="
rg -n -C2 '@Version|class Ticket|status|investigator' "$ticket_file"

echo
echo "=== TicketRepository locking APIs ==="
rg -n -C2 '@Lock|PESSIMISTIC|OPTIMISTIC|findById' "$repo_file"

echo
echo "=== TicketService lifecycle mutations ==="
sed -n '99,214p' src/main/java/org/example/alfs/services/TicketService.java | cat -n

Expected result: either a @Version field on Ticket or a locked fetch path in TicketRepository. If neither exists, these guards remain race-prone.

Also applies to: 156-176, 194-207

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/org/example/alfs/services/TicketService.java` around lines 108
- 129, The guards in TicketService (e.g., the read-check-write paths around
TicketRepository.findById(...) used in status updates and
assignInvestigator/unassign flows) are vulnerable to races; add optimistic
locking to the Ticket entity by introducing a `@Version` field on class Ticket or,
alternatively, change the repository fetches used by methods like
assignInvestigator() and the status update path to acquire a write lock (e.g.,
use a `@Lock`(PESSIMISTIC_WRITE) or a repository method that fetches with a FOR
UPDATE-style lock) and handle OptimisticLockException/lock timeouts by retrying
or returning an appropriate error; ensure the checks that inspect
ticket.getStatus() and ticket.getInvestigator() are done after the
locked/versioned fetch and before ticketRepository.save(ticket) so concurrent
mutations cannot bypass the guards.